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I .  INTR020&1I0N 


A.  BACKGROUND 

An  Integrated  Circuit  (IC)  is  a  small  silicon 
semiconductor  crystal  containing  electrical  components  sucn 
as  transistors,  diodes,  resistors,  capacitors,  or 
interconnected  digital  gates.  As  tne  tecnnology . of  IC's  nas 
improved,  tne  number  of  components  tnat  can  be  put  on  a 
single  silicon  cnip  nas  increased.  If  a  package  contains 
several  logic  gates  it  is  considered  to  be  a  small-scale 
integration  (SSI)  device.  Medium-scale  integration  (MSI) 
devices  contain  10  to  100  gates  and  perform  a  complete  logic 
function,  large-scale  integration  (LSI)  devices  perform 
logic  functions  wits  over  100  devices  and  very-large-scale 
integration  (VLSI)  units  contain  tnousands  of  gates  in  a 
single  chip.  The  INTEL  1APX  432  contains  150,000  transistors 
on  two  chips  and  is  considered  a  VLSI  device. 

B.  THESIS  DESCRIPTION 

The  Intel  432/670  system  is  a  commercial  product  tnat 
uses  tne  iAPX  432  microprocessor.  Incorporating  many  new 
architectural  features,  with  tne  goal  to  signif icantly 
reduce  the  software  cost,  tne  Intel  432  nas  been  neraldeu  as 
"the  most  significant  architectural  development  in  tne  last 
5-10  years"  [Ref.  lj .  In  addition  to  tne  VLSI  tecnnology, 
the  432  contains  architectural  advances  tnat  enable 


implementation  of  transparent  multiprocessing  and  a 
protected  computing  and  communications  environment. 

T&e  purpose  of  tais  tnesis  is  to  continue  a  series  of 
benchmark  performance  tests  on  tae  Intel  432  tnat  nave  been 
reported  in  Shoop  [Ref.  2J  and  Applegate  [Ref  3J  .  Tne  goal 
of  tnese  tests  is  to  determine  if  tae  432/672  system  is 
capable  of  sustaining  incremental  performance  improvements 
as  processors  are  added  to  tne  system. 

C.  THESIS  0R5ANIZAT0N 

Tais  tnesis  is  composed  of  tnree  major  sections.  Cnapter 
II  presents  a  brief  nistory  of  computer  architecture 
development  from  tae  first  electronic  computers  to  tae 
object  oriented  arcai tectures .  Chapter  III  provides  a 
systematic  description  of  tae  Intel  432/670  system  wane 
Chapter  17  provides  tne  actual  Benchmark  performance 
evaluations  of  the  Intel  432/670  system  in  tae 
multi  processor/multi  process  environment. 


II.  HISTORICAL  DEZ.£LOPME£tX 


Since  computer  systems  architecture  is  not  restricted  to 
the  sole  aspect  of  hardware,  it  is  not  easily  defined. 
Functional  boxes  and  their  complexity,  tne  interconnection 
between  tne  bores,  swltcnes,  controllers,  tne  way  messages 
are  passed  and  received,  and  tne  blend  of  nardware  and 
software  features  must  be  considered  in  tne  overall 
architectural  structure.  The  Intel  432  architecture  is  the 
result  of  an  evolutionary  development  in  computer  systems. 
It  incorporates  many  advanced  features  wnicn  nave  evolved 
throughout  tne  history  of  computers.  Accordingly,  to 
establisn  tne  proper  perspective  of  tne  concepts  of  tne 
Intel  432  a  brief  history  of  computer  architecture 

development  is  presented. 

One  of  tne  earlier  electronic  computers  was  completed  in 
1946  at  tne  University  of  Pennsylvania  Moore  Scnool  of 
Engineering.  ENIAC,  capable  of  performing  nearly 

additions  or  subtractions  per  second,  consisted  of  more  than 
18000  vacuum  tubes  and  1500  relays  and  was  used  to  compute 
ballistic  trajectories.  Wired  for  specific  computations,  any 
modifications  or  program  replacements  on  ENIAC  required  new 
wiring  and  its  associated  excessive  set  up  time.  In  an 
effort  to  eliminate  tne  setup  time,  von  Neumann  and  others, 
consulting  at  tne  Moore  Scnool  of  Engineering,  designed  tne 
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first  stored  program  computer.  However,  the  first 
operational  stored  program  computer  (EDSAC)  was  built  at 
Cambridge,  England  in  1949.  In  addition  to  being  tne  first 
computer  to  execute  stored  programs.  EDSAC  introduced  tne 
notion  of  memory  nierarcny  tnrougb  tbe  primary  memory  and 
backing  drum. 

Meanwnile,  von  Neumann  continued  nis  researcn  at  the 
Institute  for  Advanced  Studies  (IAS)  at  Princeton  wnere  ne 
developed  tne  von  Neumann  architecture  wnich  is  in  wide  use 
today.  Tne  von  Neumann  architecture  is  considered  to  be 
based  on  four  key  concepts: 


1 . 

A  single. 

sequentially 

addressed 

memory.  A 

program  and 

its  data  are 

stored 

in  a 

single 

memory,  and 

the  memory 

is  refe 

rencea 

with 

sequential  addresses. 

2. 

A  linear 

memory.  Tne 

memory 

is 

one 

dimensional , 
of  words. 

or  nas  tne 

appearance 

of 

vector 

3. 

No  explicit 

distinctions 

between 

instructions 

and  data. 

Instructions 

and 

data 

are 

dlstinqulsned 

implicitly 

by  tne 

ope  rations 

directed  toward  them. 

4. 

Meaning  is 

not  an  inherent  part 

of 

data  . 

[Ref.  4j 

The  early  programming  styles  supported  single  user,  non¬ 
subroutine  environments  tnat  employed  a  looping  technique  by 
modifying  instructions.  Since  instruction  modification 


generated  only  serially  reuseable  code,  multiprogramming  was 
not  feasible  and  index  registers  were  developed  at  tne 


university  of  Mancnester  to  make  It  possible  to  call 
subroutines,  pass  parameters,  and  generate  reentrant  code. 

0NI7AC  I,  built  for  tfle  bureau  of  Census,  fiad  a  tape 
system  tnat  used  error  cneeking  procedures  and  buffering 
capabilities  to  read  tapes  botb  forward  and  backward.  It  was 
intended  for  botn  scientific  and  commercial  applications  and 
can  be  considered  tne  first  successful  commercial  computer. 
Tne  system  arcnitecture  durine  tnis  period  is  cnaracterlzed 
in  Figure  2.1. 


MEMORY 


PERIPHERALS 


Figure  2.1  Early  System  Arcnitecture 


As  computer  applications  advanced  into  commercial 
fields,  I/O  intensive  requirements  were  generated. 


Architecture  improvements  to  ennance  computational  speeds 
and  enable  overlap  to  permit  interleaved  I/O  and 
computational  operations  were  developed.  Pipelining,  a 
technique  used  to  speed  computer  operations  by  multiplexing 

memory  accesses  .pa  with  instruction  decoding  and  execution, 
is  one  example  of  ennancement. 

Systems  became  faster,  smaller,  and  more  reliable 
throughout  the  1960's  as  transistors  and  integrated  circuits 
allowed  the  building  of  more  general  purpose  registers  and 
regular  arcnitectures .  Figures  2.2,  2.3,  and  2.4  depict  the 
architectures  of  this  period. 


MEMORf 


i 

i 

i 

PERIPHERALS 


Figure  2.2  Dual  Port  Memory  Architecture 


Figure  2.2,  representing  a  dual  port  memory 


arcnltecture,  provides  a  faster  access  path  but  demands 
extra  hardware  in  the  memory  which  performs  independent  I/O 


operations.  The  I/O  bus  structure.  Figure  2.3,  connects  tae 
I/O  devices  to  memory  tnrougn  device  controllers  tnat.  are, 
in  many  cases*  mini-computers.  It  still  requires  a  resource 
manager  or  a  dlstrl&uted  control  discipline.  Tae  central 
system  controller  shown  in  Figure  2.4  is  Based  around  a 
giant  switch  which  controls  multiple  processors  and  memory 
units  in  a  modular  fashion. 


CPU 

» 

\ 


MEMORY 


DEVICE  i  !  DEVICE  i  !  DEVICE  ! 

|  CONTROLLER  !  !  CONTROLLER  !  !  CONTROLLER  ! 


Figure  2.3  I/O  Bus  Architecture 

As  hardware  cost  decreased,  designers  eliminated  tae 
complicated  central  I/O  control  in  favor  of  a  bus  oriented 
structure  (Figure  2.51.  It  is  flexioie,  modular,  and 
conceptually  simple  and  most  architectures  today  contain 
variations  of  this  bus  oriented  structure.  S-100,  MULTIBUS, 
SXORBUS ,  and  VMEBus  are  a  few  bus  oriented  architectures  on 
tne  current  mariet. 
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As  fast  processors  were  developed,  efforts  to  keep  the 
processors  busy,  wnile  tne  slow  peripnerals  were  reacting  to 
Instructions,  culminated  In  multiprogramming  and  the 
associated  task  swltcning  and  Hardware  memory  protection 
instruction  set  enflancements .  Microprogramming,  a  technique 
which  breaks  each  instruction  into  a  series  of  elementary 
steps  was  also  developed  in  the  1960 's  to  reduce  the  cost  of 
the  sophisticated  instruction  sets  by  making  it  easier  to 
develop  a  compatible  series  of  computers  that  covered  a  wide 
ram?e  of  performance. 

Paging  and  segmentation  were  developed  to  support  tne 
concept  of  virtual  memory.  Additionally  cacne  memory,  wnicn 
is  fast  memory  pnysicaiiy  close  to  tne  central  processor, 
was  developed  to  improve  CPU  performance.  In  esneral,  the 
advances  in  memory  management  resulted  in  a  five  level 
hierarchy  that  consisted  of  registers,  cache,  main  memory. 
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and  high-speed  dlsfc  or  drum  for  oacicing  store  and  low-speed 
disx  or  tape  for  long-term  program  storage. 


MEMORY 


!  I/O  ! 

!  PROCESSOR  | 


MEMORY  |  !  CPU 

i  i 


|  COMMUNICATION  |  !  CPU 

!  PROCESSOR  i  ! 


Figure  2.5  Single  Bus  Arcnitecure 


Multiprocessors,  another  concept  introduced  in  tne 
1960 's ,  are  cnaracterlzed  arcnitecturaiiy  by  wnetner  tne 
processors  are  identical,  execute  the  same  instruction 
stream,  or  operate  on  one  or  more  data  streams.  However,  it 
was  the  Intel  4004  microprocessor  which  was  developed  in 
1971  that  was  responsible  for  a  continued  unpresidented 
evolution  m  technology  during  the  1970's  which  produced  tne 
Inexpensive  processors  and  encouraged  the  use  of 
multiprocesssing.  Specialized  database  processors  and 
arithmetic  processors  are  a  few  examples  of  expansion  in 
tnls  area. 

As  complexity  in  microcomputer  systems  increased  with 
decreasing  hardware  cost,  software  systems  were  expanding  to 
taxe  advantage  of  the  new  capacities.  Software  engineers 
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soon  discovered  mat  large  software  systems  were  among  tne 
most  difficult  engineering  projects.  The  use  of  subroutines, 
bloct  structured  languages,  procedures,  functions,  stepwise 
refinement  and  structured  programming  were  techniques 
developed  to  assist  in  solving  tne  software  engineering 
problems.  Data  abstraction,  employing  tne  concepts  of 
encapsulation  of  data  structures,  uniform  procedure/message 
interface,  and  decomposition  of  design,  was  a  furtner 
extension  of  tne  effort  to  produce  reliable  software, 
irfnile  tnese  software  concepts  were  being  developed, 
evolution  in  hardware  protection  structures  can  be  observed 
in  "supervisor  vs.  user  state  in  tne  IBM  3S0  systems, 
nlerarcnicai  rings  in  Multlcs,  and  multiple  domains  In  tne 
Plessy  s/250,  CAL/TSS,  Hydra,  and  CAP.  Key  concepts  of  tnese 
domain  cased  systems  Include  independent  address  spaces, 
capability-based  addressin*  and  access  control,  and  tne 
decomposition  of  tne  operating  system  into  a  useful  set  of 
abstractions."  [Ref.  5j  Additionally  descriptors  and  access 
control  concepts  were  introduced  to  provide  protection  by 
establisnin*  a  reaulrement  for  authorization  to  access  data 
elements . 

A  major  departure  from  one  of  the  Key  concepts  of  the 
von  Neumann  architecture  is  observed  In  tagged  storage.  All 
Information  witnin  storage  Is  self-identifying.  Based  on  tne 
information  contained  in  the  ta*  field,  the  machine 
instructions  can  determine  tne  semantics  of  eacn  operation 


as  well  as  t ne  data  conversion  rules  to  employ.  rfitn  the 
tag  field  you  nave  a  strongly  typed  environment'  tnat 
prohibits  operation  on  improper  data  types  and  permits  tne 
deferment  of  binding  Instructions  to  data  attributes  until 
tne  time  of  execution. 

As  we  examined  tne  nistory  of  computer  development,  we 
saw  tttat  tfte  early  machines  used  simple  hardware  operations 
sucn  as  "move  byte"  and  "add  integer"  wnlch  manipulated 
hardward-recoenized  data  types  sucn  as  bytes  and  integers. 
As  technology  progressed  and  computer  hardware  gained 
functionality,  more  complicated  operations  sucn  as  floating 
point  were  moved  into  hardware,  which  substantially 
increases  tne  speed  of  tnese  operations.  Enhancement  of 
standard  programming  methods  as  well  as  guaranteed 
enforcement  of  data  protection  were  additional  benefits 
derived  from  moving  software  functions  into  hardware. 

Recognizing  tnat  continued  advancements  in  architectural 
enhancement  would  result  in  more  data  structures  being  moved 
into  hardware,  designers  developed  a  methodology  for  viewing 
these  abstractions  that  would  contribute  to  tne  concept  of 
raising  the  level  of  hardware/software  interface.  One  sucn 
methodology  tnat  Integrates  data  abstraction,  domain  based 
protection,  and  nign  level  system  functionality  is  tne 
object  oriented  methodology. 

The  concept  of  using  objects  can  be  observed,  as  long 
ago  as  I960,  in  LISP,  wnere  atoms  nave  properties  tnat  can 
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be  related  to  real  world  objects.  SIMULA,  an  extension  of 
ALU OL  intended  for  simulation,  included  tne  idea  of 
internally  represented  objects  as  Instances  of  classes.  In 
an  effort  to  produce  a  programming  vehicle  tnat  would  reduce 
tne  man-macnine  semantic  gap,  Alan  Kay,  wnile  still  a 
Graduate  student  at  the  University  of  Utah,  investigated 
simulation  and  graphics  oriented  programming  languages. 
Taiing  many  of  nis  ideas,  sucn  as  classes  and  objects,  from 
SIMULA,  Kay  helped  design  the  lan/ruaee  FLEX.  Continued 
refinement  of  FLEX  carried  tne  object  oriented  paradigm  to  a 
smoother  model  by  incorporating  ideas  from  LOGO,  a  language 
designed  to  teacn  programming  concepts  to  cnlldren,  and 
resulted  in  the  Smalltalk  pro*rammin*  system. 

An  object  is  an  abstraction  tnat  is  usually  considered 
to  have  the  following  characteristics: 

1.  objects  are  temporal?  they  exist  in  time? 

2.  objects  are  mutable  (subject  to  change) ,  and  have  a 
state; 

3.  objects  can  be  created  and  destroyed? 

4.  objects  are  particular  (distinct),  and  can  oe 
shared.  [Ref.  to J 

In  general  objects  are  similar  to  packages  in  tnat  an  object 
is  a  data  structure  that  contains  information  in  an 
organized  manner,  including  a  set  of  basic  operations  tnat 
directly  manipulate  the  data  structure.  It  can  be  referenced 
as  one  entity  and  has  a  label  that  tells  its  type. 


As  Kay  continued  his  concept  development  throughout  tne 
1970's,  tne  Idea  of  using  an  object  oriented  metnodology  to 
model  complex  real  world  Issues  began  to  emerge.  IBM  uses 
object  oriented  design  concepts  for  complex  projects.  Grady 
Booch,  formally  of  tne  USAF  Academy,  advocates  an  object 
oriented  design  using  Ada  to  enforce  a  clear  design 
structure.  Just  as  Smalltalk  nad  used  objects  to  represent  a 
desired  level  of  abstraction,  object-based  arcnitecture  was 
selected  to  model  the  growing  hardware  complexities. 

Based  on  an  Integrated  approach  to  data  abstraction  and 
domain-based  protection,  object  oriented  architecture 
Includes  a  form  of  capability  based  addressing  and  supports 
high  level  system  functions  such  as  memory  management, 
process  management,  and  processor  management.  Eecause  the 
architecture  is  rooted  in  data  abstraction,  good  software 
design  methodology  is  encouraged  which  will  result  in 
software  systems  that  will  be  more  reliable  and  nave  reduced 
software  life  cycle  cost.  Elements  of  object-oriented 
arcnitecture  Include: 

1.  Objects  for  system  management  and  control. 

2.  Objects  for  program  environments,  flow  of  control, 
and  intercommunication. 

3.  Facilities  for  user  object  extensions  and  system 
object  type  management. 

4.  Object  addressing  and  protection  mechanisms. 

5.  An  Instruction  interface.  IHef.  7J 


24 


System  management  objects  Include  processor  objects, 
process  objects  and  resource  objects,  While  a  processor 
object  is  a  memory  based  data  structure,  process  objects 
represent  a  unit  of  computational  wort  for  tne  processor  and 
contain  information  regarding  scheduling  and  dispatcning. 
Various  resource  objects  are  queue-iiice  structures  used  to 
bind  physical  processors  with  realy-to-run  processes.  By 
representing  all  resources  as  objects,  a  uniform  interface 
for  all  system  functions  is  obtained. 

Environment  and  control  objects  include  data  objects, 
instruction  objects,  domain  objects,  context  objects  and 
control  Unit  objects,  while  communica  tion  objects  consist  of 
message  and  port  objects.  Port  objects  are  asyncnronous 
communication  pathways  between  processes  and  provide  for  the 
queueing  of  waiting  messages  as  well  as  resolution  of  speed 
disparity  between  concurrent  activities  in  the  system.  An 
object  oriented  architecture  with  a  built  in  software 
methodology  snould  include  support  for  representing  typing, 
type  manager  packaging,  and  object  authentication  and 
creation.  Object  addressing  and  protection  mechanisms  are 
required  to  support  references,  mapping  and  protection. 
Finally,  the  object  oriented  instruction  interface  provides 
a  uniform  interface  with  uniform  referencing  to  all  tne 
object  based  facilities. 

A  system  environment  can  be  viewed  as  a  single  set  of 
objects  which  are  addressable  by  everyone.  Ranging  from  tne 
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primitive  storage  segment  Having  all  tne  cnaracterlstlcs  of 
a  von  Neumann  store,  to  an  abstract  entity  wnose  physical 
form  is  nldden  by  tne  architecture  and  wnose  meaning  Is 
defined  solely  by  tne  transformations  tnat  can  be  performed 
on  It,  objects  provide  still  more  protection  by 
encapsulating  data  and  program  modules  in  a  structure  with 
not  only  well  defined  external  visibility  but  carefully 
nldden  internal  structure. 

In  summary,  object  oriented  arcnitectures  were  adapted 
to  model  the  wide  variety  of  hardware  and  software 
constructs  that  have  been  developed  to  ennance  computer 
systems  efficiency  and  reliability.  In  addition  to  raising 
the  level  at  which  tne  transition  from  hardware  to  software 
occurs,  object  oriented  architecture  enjoys  technology 
Independent  design  through  its  information  hiding  structures 
and  supports  a  variety  of  language  structures  including 
operating  systems  anl  reliable  low  life  cycle  cost 
applications  software.  For  tnese  reasons,  Intel  Corporation 
has  chosen  the  object-oriented  architecture  as  the 
predominant  construct  of  the  iAPX  432. 


III.  INTEL  £32/670  SYSTEM  DES£RI£tlON 
MFcOMPOnInT  AR£|IflCT2Rl” 

Tills  chapter  will  present  the  cftaracteristlcs  and 
advantages  of  tne  1APX432  over  tne  conventional 
microcomputers.  Additionally,  tne  concepts  of  object 
oriented  architecture  will  be  presented  in  a  simplified 
form. 

A.  THE  432  OBJECT  ORIENTED  ARCHITECTURE 

In  an  effort  to  find  a  solution  to  the  software  crisis 
wniie  providing  transparent  multiprocessing,  tne  Intel  432 
designers'  principal  desire  was  to  provide  direct  execution 
time  support  for  both  data  abstraction  and  domain-Dased 
operating  systems.  Recognizing  tnat  botn  of  tne  objectives 
could  be  supported  by  tne  object  model,  Intel  selected  tne 
object  oriented  arcnitecture  as  tne  principal  design 
construct  to  support  a  software  methodology.  This 
arcnitecture  provides  mecnanisms  to  help  tne  programmer 
follow  the  object  oriented  methodology. 

1  •  Object  Or ieni§£  Mg»t ao£o logy 

Wn at  does  object  oriented  methodology  mean?  One  of 
the  best  ways  to  modularize  programs  is  by  using  the 
principle  of  information  aiding  as  defined  by  D.  L.  Parnas. 
The  basic  idea  is  that  a  module  should  contain  a  collection 
of  related  procedures  and  associated  data  structures  on 
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wnicn  tney  operate.  Procedures  outside  tne  nodule  should  not 
nave  access  to  the  implementation  details  inside  the  module. 
Tne  data  can  be  referenced  from  outside  tne  module  only  by  a 
call  to  one  of  tbe  procedures  Inside  the  module. 

Modules  tnat  result  wnen  tnis  principle  is  applied  are 
referred  to  as  abstract  data  types,  extended  types,  or 
Parnas  modules.  Intel  refers  to  tnem  as  type  managers. 

At  the  same  time  that  programming  languages  research  was 
focusing  on  tne  concept  of  a  type  manager  as  the  solution 
to  the  modularization  problem,  operating  system  research  was 
defining  a  very  similar  structure,  tne  protection  domain, 
as  the  solution  to  the  security  problem.  Since  operating 
system  personnel  were  concerned  more  with  security  than 
modularization,  they  concentrated  on  the  data  in  these 
domains,  rather  than  tne  procedures  which  were  the  rocus  of 
the  language  research.  Assigning  the  name  "objects"  to  tne 
data  items  associated  with  domains,  operating  systems 
personnel  called  the  whole  information  hiding  methodology 
object  eitner  tne  oriented  metnodoiogy  or  tne  object  model. 

Although  experimental  studies  have  demonstrated  that 
objects  are  superb  models  for  modern  software  systems,  the 
overhead  required  to  maintain  tne  model  is  too  excessive  to 
permit  efficient  Implementation  without  direct  hardware 
support.  [Ref.  S.J  The  Intel  432  has  hardware  mecnanisms 


that  permit  recognition  of  the  following  objects: 


1.  Processor 

2.  Processes 

3.  Dispatchin*  ports 

4.  Interprocess  messages 

5.  Domains 

6.  Context 

7.  Instruction 

S.  Data 


to  permit  an  effective  management  of  tne  system's 
configuration  and  its  individual  resources  as  wen  as 
support  for  data  abstraction. 


B.  INTEL  432/670  SYSTEM 

Utilizing  tne  advanced  arcnitecture  of  tne  1APX  432 
Micromainframe  VLSI  computer,  tne  432  family  presents  a  new 
arcnitecture  in  tne  world  of  microcomputers  wnicn  contains 
tne  following  salient  characteristics . 


the  operating  system  is  contained  in  silicon 
is  called  Tne  Silicon  OS.  It  supports 
scheduling,  interprocess  communication  and 
storage  allocation. 

2.  Tne  system  operates  in  botn  single  processor  and 
multiprocessor  conf ieurations  and  it  can  include  up 
to  eignt  (8)  processors,  aitnougn  tne  432/670  system 
can  only  support  five  (5)  processors  as  limited  by 
tne  number  of  slots  available  in  tne  motner  board. 
If  one  processor  fails,  tne  rest  of  tne 
system  can  usually  continue  to  operate. 

3.  Hardware  recognition  of  eignt  (8)  data  types. 

4.  Hardware  control  functions  for  16  and  32  bit 
multiply,  divide,  and  remainder  operations. 

5.  Hardwired  control  functions  for  32,  64,  and  80 

bit  floating  point  arltnmetic. 

6.  Hardwired  error  correction  and  code  protection. 

7.  Object  oriented  desien. 


1.  Part  of 
and  it 
process 
dynamic 


8.  Both  abstract  data  types  and  objects  are  supported 
by  hardware  recognized,  hardware  protected  and 
hardware  manipulated  structures. 

9.  It  has  an  extremely  large  virtual  address  space 
(2**40  bytes)  and  hardware  supplied  mechanisms  for 
implementing  virtual  memory  systems  that  can 
exploit  this  address  space. 


The  432/670  system  consists  of  tne  three  (3)  subsystems: 


1.  Memory  subsystem.  \  Central  System 

2.  Processor  subsystem.  / 

3.  Peripheral  subsystem. 


and  two  busses: 


1.  System  bus  backplane. 

2.  Multibus  backplane. 


Before  analyzing  eacn  one  tne  subsystems,  tne  following 
observations  of  tne  systems  architecture  are  germane: 


1.  Tne  whole  memory  is  accessible  by  all  GDPs. 

2.  The  system  is  theoretically  expandable  to  include 
any  number  of  processors  (GDPs). 

3.  8  bit  or  16  bit  based  systems  can  be  connected 
to  tne  system  for  performing  I/O. 


Figure  3.1  Illustrates  the  boundary  between  tne  central 
system  and  peripheral  subsystems.  In  addition  to  seperating 
data  processing  from  Input/output  processing,  this  boundary 
serves  as  a  protection  barrier.  All  information  in  central 
system  memory  is  snielded  by  432  hardware  against 
unauthorized  accesses  but  the  peripheral  subsystem  may  or 
may  not  provide  protection. 
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Figure  3.1  General  432/670  System  Organization. 

Figure  3.2  Illustrates  a  hypothetical  configuration  that 
employs  two  peripheral  subsystems.  The  main  system's 
hardware  Is  composed  of  two  GDPs  and  a  common  memory  tnat  Is 
snared  by  tnese  processors.  The  main  system's  software  Is  a 
collection  of  one  or  more  processes  that  execute  on  the 
5DP(s ) . 


Si/o ! 


Figure  3.2  Main  System  and  Peripheral  Subsystem. 
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When  the  salient  characteristics  of  the  432  are  viewed 


wltn  respect  to  toe  levels  of  arcnitecture  within  a 
computing  system  cited  by  Meyers  (Ref.  9],  it  becomes  clear 
that  functions  have  been  moved  from  botn  high  level 
language  and  operating  system  to  the  hardware  which  raise 
the  boundary  line  between  hardware  and  software  closer  to 
the  end  user.  Figure  3.3  Illustrates  the  hardware-software 
Interface. 


1APX  423  mainframe 
minicomputer 
microcomputer 

Figure  3.3  Hardware  -  Software  Interface 

Appendix  A  gives  a  comparison  of  tne  1APX  432 
arcnitecture  and  tne  architecture  of  tne  conventional 
mal nf rames . 

1.  Central  Sysiajn 

Tne  central  system  consists  of  tne  memory  and  the 
processor  subsystems. 

a.  Memory  Subsystem 

The  memory  subsystem  resides  on  tne  system  bus 
bacKplane  and  consists  of: 


applications 


nigh  level 
language 

operating  system 

basic  instruction 
set 

gate  level  etc 


1.  One  memory  controller  (MC)  Board. 

2.  One  to  Ten  Storage  Array  ( S A )  Boards. 

3.  A  Memory  Interleave  (option). 


(1)  Memory  Controller  Bfiarjl.  Tne  memory 
addressed  by  toe  432  is  organized  in  eignt-Bit  Bytes.  In 
spite  of  this  Intel  says  that  the  432  is  a  32  bit 
microprocessor  and  that  it  can  perform  32,  64,  and  80  bit 
floating  point  aritnmetic  Because  with  any  read  request  from 
the  system  processors ) ,  an  additional  signal  determines  now 
many  bytes  should  be  addressed.  Tnis  is  called  byte 
addressability.  Thus,  based  on  the  processor(s)  requests  a 
word  can  consist  of  1,  2,  4,  8,  or  10  bytes  and  consequently 
8,  16,  32,  48,  64,  or  80  bits  can  be  addressed. 

(2)  Storage  Array  Baard.  Each  Storage  Array 
(SA)  board  contains  256K  8  bit  Bytes  of  memory.  A  memory 
controller  can  control  up  to  16  SA's  or  4.096  Megabytes  of 
memory.  However,  in  tne  current  432/670  systems . there  are 
only  10  slots  available  for  SA  boards. 

Although  the  432  is  a  32  bit  microprocessor 
tne  words  are  organized  in  39  bit  wide  banes.  Tne  seven  (7) 
additional  bits  contain  Error  Correction  Code  (ECD)  for  each 
32  Bit  word.  Tnis  is  controlled  by  logic  existing  on  every 
SA  board  for  venerating,  checking  ana  btorinv  this  ECD. 
Finally,  tne  SA  boards  are  organized  in  64E  byte  Bants  of  32 
bit  words,  four  bytes  per  word. 

(3)  laiSliSilS  Oslisa*  This  option  can  be 
selected  by  setting  tne  jumpers  of  tne  MC  board  to  tne 


proper  position.  Tne  interleave  option  is  available  to 
enhance  system  performance.  The  interleave  concept  uses  two 
banks  of  memory  with  alternating  addresses  to  provide  faster 
data  access  by  overlapping  memory  operations.  If  tne 
interleave  option  has  been  selected*  SA  boards  must  be 
Installed  in  pairs  to  provide  tne  alternate  banKS. 

b.  Processor  Subsystem 

The  processor  subsytem,  which  resides  on  the 
system  bus  backplane  and  consists  of  tne  GDP  and  IP  boards* 
is  discussed  under  component  architecture. 

c.  Peripheral  Subsystem 

The  peripheral  subsystems  are  discussed  in  the 
Basic  I/O  Model  and  Windows  sections. 

C.  COMPON5NENT  ARCHITECTURE 

In  this  section,  the  basic  architecture,  of  the  major 
components  of  tne  system  (  GDP  and  IP)  are  presented. 

1 •  Architecture 

The  432  GDP  consists  of  two  chips  the  instruction 
decoder/microinstruction  sequencer-43201  and  tne  execution 
unit-43202.  Appendix  B  contains  the  pin  description  of  each 
chip  while  Figures  3.4,  and  3.5  show  the  block  diagrams  of 
the  43201  and  43202  chips  respectively. 

In  general,  the  GDP  is  organized  internally  as  a 
three-staee  microprogram-controlled  pipeline.  The  first 
stage  is  the  instruction  decoder  (ID),  the  microinstruction 
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sequencer  (MS)  is  contained  in  tne  second  stase  wnile  tne 
tniri  stage  nouses  tne  execution  unit. 


Tne  first  two  stages  of  tne  pipeline  are  pnysicaily 
located  on  tne  43201  cnip  (figure  3.4),  wnile  tne  tnlrd 
staee  is  the  only  function  of  the  43202  chip  (Figure  3.5). 
Actually  each  stage  of  tne  pipeline  is  an  independent 
subprocessor,  wnicn  operates  until  tne  pipeline  is  full  and 
then  halts  and  waits  for  additional  worjc. 
a.  Instruction  Decoder 

The  first  subprocessor  of  tne  pipeline  is 
the  Instuctlon  Decoder  (ID),  which  performs  the  following 
functions : 


1.  Receives  macroinstructions. 

2.  Processes  variable  length  ields. 

3.  Extracts  logical  addresses. 

4.  Generates  starting  addresses  for  micro¬ 
instruction  procedures 

5.  Generates  micro-instructions  for  simple 
operations . 


The  general  tast  facing  tne  Instruction 
Decoder  is  to  interpret  the  macro-instruction  stream,  to 
determine  wnicn  micro-instruction  sequence  should  oe 
initiated  next  and  to  extract  logical  address  data. 
Additionally,  the  Instruction  Decoder  provides  a  mechanism 
to  recover  from  an  instruction  that  faults.  The  information 
necessary  for  fault  recovery  is  retained  by  the  Instruction 
Decoder  until  the  Instruction  is  successfully  completed. 
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Figure  3.4  43201  Bloc*  Diagram, 
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n.  Microinstruction  Sequencer 

Tae  second  subprocessor  in  tne  pipeline  is 

tne  Microinstruction  Sequencer  (MS).  Tne  role  of  tne 
Microinstruction  Sequencer  is  to  decide  wnicn 
microinstruction  should  be  sent  to  the  Execution  Unit  for 

each  cycle. 
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c •  f x££uiiaa  Sail 

The  43202  contains  the  Execution  Unit  (EU) 
which  is  tnird  stage  of  tne  GDP  pipeline.  This  unit  receives 
microinstructions  from  the  43201  and  routes  them  to  one  of 
the  two  independent  subprocessors  that  malce  up  the  EU,  tee 
Data  Manipulation  Unit  (DMU)  or  tne  Reference  Generation 
Unit  (RGU ) . 


POLE/ 


mI15. . .m!0 


CLR/ 
IS6. 


Da  ta 

Manipulation 

Unit 


i 
i 

.  *  __ 


.  IS0 


i  -  {Reference 

!<=!Control {=>{ Generation 
!  {Decoder!  {  Unit 


{System! 
■>!Timers  !< 


>!Processor  !<- 
{Pacfcet  Bus!  — 
!  Control  { 


-MASTER 

->HERR/ 


BOUT'  ICS  {  ACD15.  . .  A.CD0 

i 

PRO 


Figure  3.5  43202  Bloc*  Diagram. 


The  Data  Manipulation  Unit  contains  tne 
registers  and  arithmetic  capabilities  necessary  to  perform 
hardware  recognition  of  eight  (S )  lata 

types,  16,  and  32  bit  multiply,  divide,  and  remainder 
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operations.  Additionally  it  contains  the  control  functions 
for  32,  64,  and  80  bit  floating  point  arithmetic. 

The  Reference  Generation  Unit  proviaes  the 
translation  of  a  40  bit  virtual  address  into  a  24  bit 
physical  address,  a  hardware  enforced  domain  protection 
system  (read,  write,  alter,  accessed),  handling  sequencing 
for  8,  16,  32,  64,  and  80  bit  memory  accesses,  and 
controiing  tne  on-caip  top-of-stack  register.  In  general, 
tae  Execution  Unit  manipulates  data  and  translates  tne 
logical  addresses  into  physical  addresses. 

d.  Processor  Packet  Bus  Definition 

Tne  Processor  Packet  Bus  contains  19  signal 
lines.  Sixteen  (16)  signal  lines  are  the  three-state 
Address-Control-Data  lines  (ACD15  througn  ACD0 )  and  tne 
remaining  three  are  control  lines  used  to  request  the  bus, 
enable  the  buffers  for  output  from  and  an  interconnect 
status  line.  In  general  by  sending  tne  proper  signals,  tne 
system  bus  is  used  as  an  address,  control  or  data  bus.  Tne 
mecnanlsm  for  tnls  multi-use  of  tne  system  bus  is  quite 
complex  and  it  is  explained  in  Intel's  manuals. 

2 •  Interface  Processor 

The  Interface  Processor  (IP)  interfaces  tne  GDP's 
and  tne  employed  peripheral  subsystems  by  providing  I/O 
facilities.  An  IP  maps  a  portion  of  tne  peripheral  address 
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different  objects  located  In  main  memory, 
protection  mecnanisms  as  any  1APX  432  processor.  Figure  3.6 
Illustrates  tne  Internal  arcnitecture  of  tne  Interface 
Processor. 


CLKA.CLKB 

Figure  3.6  Interface  Processor  Blocs  Dia*ram. 

D.  DATA  MANIPULATION 

1.  Harlvir”  SfiMsnllfil  IlfiCS 

Computers  store  data  In  tnelr  memory  in  terms  of 
zeros  and  ones,  kfnat  tnese  strings  of  bits  represent  depenas 
upon  the  Interpretation  given  to  them  by  tne  computer.  This 
means  tnat  two  or  more  different  pieces  of  Information  might 


be  represented  by  exactly  the  same  string  or  olts  and  so 
this  string  could  be  lnterperated  as  an  Instruction, 
Integer,  or  character.  These  basic  representations  are 
called  nardware  recognized  data  types  and  nave  tne  following 
characteristics: 

1.  Each  Instance  of  a  type  is  an  addressable  unit 
of  memory. 

2.  Eacn  type  nas  associated  witn  it  a  set  of 
operations  that  can  be  performed  on  tnls  type. 

The  combination  of  all  tne  hardware  recognized  data 
types  with  all  the  operators  which  act  upon  them  constitute 
the  instruction  set  of  tne  computer.  Tpese  hardware 
recognized  data  types  are  called  primitive  data  types 
because  they  are  used  to  construct  more  complex  data 
structures . 

Tne  Intel  432  recognizes  eight  different  primitive 
data  types,  wnich  are  dlvidel  into  four  classes:  Characters, 
Ordinal  (unsigned  integers  16  and  32  bits  long).  Integer  and 
Real.  Figure  3.7  provides  tne  formats  of  eacn  of  tne  eight 
hardware  recognized  data  types  iRef.  15). 

2.  Structured  Data  Type* 

The  term  structured  data  types  is  used  for  ordered 
aggregates  of  primitives.  Tne  two  structured  data  types  tnat 
can  be  accessed  by  the  432  are  Arrays  and  Records.  Although 
not  supported  by  hardware,  the  432  provides  a  mechanism  that 
allows  structured  data  types  to  be  manipulated  easily. 
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3  •  laiiiiisiiani 


The  instruction  set  of  tne  432  is  rich  and  supports 
fire  out  of  tne  six  operations  which,  according  to  Myers 
[Ref.  10],  a  language  directed  architecure  must  provide.  It 
supports  string  processing,  arithmetic  operations,  program 


flow. 
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tracing. 
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the 

edi ting 

operation. 
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Instruction  set  is  contained  in  Myers  LRef .  11 J  . 

4 .  Instruction  Fpruia; 

The  instruction  format  of  the  432  has  four  fields. 
The  first  field  (class)  specifies  now  many  operands  are  in 
tne  instruction.  The  second  (format)  specifies  new  the 
operands  are  to  be  accessed.  The  third  (reference)  specifies 
tne  logical  addresses  of  up  to  three  operands.  Finally,  tne 
fourth  field  (operator  code)  specifies  tne  operator.  The 
segment  selector  identifies  the  segment  that  contains  the 
operand,  while  the  displacement  locates  the  operand  within 
the  segment.  Figure  3.9  illustrates  tne  lnstuction  format, 
b .  Addressing  Moaes 

The  base  and  index  values  are  used  to  locate  the 
operand  witnln  tne  segment  eltner  by  containing  tne  value 
itself  (direct  addressing)  or  by  pointing  to  a  location 
wnlcn  in  turn  points  to  tne  location  where  tne  value  of  the 
operand  has  been  stored  (indirect  addressing). 


42 


/ 

/ 


Figure  3.8  1APX  432  Instruction  Format  (tnree  operands^ 

A  number  of  combinations  (base  direct/lndi rect  and 
index  direct/indirect)  of  direct  and  indirect  reference  are 
called  addressing  modes.  The  system  selects  the  most 
efficient  way  for  addressing  tne  various  data  types  as 
follows : 

1.  Base  and  Index  Direct  :  used  to  access  scalars. 

2.  Base  Indirect,  Index  Direct  :  used  to  access 

records. 

3.  Base  Direct,  Index  Indirect  :  used  to  access 

static  arrays. 

4.  Base  and  Index  Indirect  :  used  to  access  dynamic 
arrays . 


Figures  3. 94  and  3.9B  illustrate  tne  four  addressing  modes 


Scalar:  Index  and  Base  Specified  Directly 
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Figure  3.9A  Addressing  *odes 
6 •  Operand  S  tack 

A  special  data  segment  maintained  by  tne  nardware 
for  expression  evaluation  is  called  tne  operand  stack. 
Accesses  to  tne  top  of  tne  operand  stack  are  called  implicit 
references  and  tne  items  are  added  to  or  removed  from  tne 
stack  on  a  last-in  first-out  (LIFO)  policy.  Tne  current 
stack  top  is  pointed  to  by  a  hardware  maintained  stack 


Static  Array:  Index  Specified  Indirectly 
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Dynamic  Array:  Base  and  Index  Specified  Indirectly 
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Figure  3.9B  Addressing  nodes 


7 .  IfiSirucilan  Snjioilng 

An  effort  nas  been  to  speed  up  execution  trirougn 
Instruction  decoding.  A  large  percentage  of  a  computer's 
time  is  spent  fetching  instructions;  nence  tne  faster  tne 
instuctions  can  be  fetched  tne  less  time  will  be  spent 
waiting  to  execute  an  instruction. 

The  432  uses  bit-variable  instructions  versus  tne 
fixed-size  length  which  is  used  oy  most  machines.  Tnis 
flexibility  implies  tnat  there  is  no  constraint  for  the 
instructions  to  start  or  to  end  on  byte  or  word  boundaries. 
The  size  of  the  instructions  varies  from  6-bit  long  for  the 
shortest  up  to  344  bits  long  for  the  longest  instruction. 
Another  difference,  in  the  instruction  encoding,  is  tnat  in 
instructions  lixe  A  *  A  *  B,  the  operand  A  need  to  be 
referenced  only  once  since  tne  format  field  in  the 
instruction  indicates  now  many  times  a  particular  operand  is 
used. 

E.  MEMORY  ORGANIZATION 

The  term  memory  organization  comprises  two  distinct 
aspects  of  a  computer's  memory.  One  is  the  hardware 
structure  of  tne  memory,  while  the  other  is  the  method  by 
which  the  memory  can  be  addressed. 

In  general  all  memory  is  structured  linearly,  differing 
only  in  tne  number  of  bits  per  byte  and  the  way  a  byte  is 
addressed.  Memory  is  addressed  through  tne  address  pins  of 
tne  CPU,  which  are  connected  to  the  decoder,  and  translated 
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to  addresses.  Since  mere  are  no  gaps  in  me  sequence  of 
numbers  produced  by  me  decoder,  any  memory  is  addressed 
linearly.  However,  if  you  loo*  at  memory  from  tne  users 
point  of  view,  a  memory  is  said  to  be: 

1.  Linear  if  the  user  can  address  it  linearly. 

2.  Segmented  if  tne  user  can  address  olochs  of 

linear  address,  where  each  space  is  called  a 
segment . 

8ach  item  within  a  segment  is  addressed  by  a  two 
component  address: 

1.  The  segment  selector  wnich  specifies  the  segment. 

2.  The  displacement  wnich  specifies  tne  offset  from 
the  base  of  the  segment  to  the  item  being  selected. 

1.  Segmented  Mfimflr* 

In  general,  mapping  is  performed  via  tne  segment 
discriptors  tnat  are  maintained  in  tne  segment  table.  Fach 
segment  nas  a  corresponding  segment  descriptor  wnicn 
contains  the  starting  physical  address  and  the  length  of  the 
segment.  Tnis  mapping  is  illustrated  in  Figure  3.10. 

The  segment  selector  of  a  logical  address  is 
used  as  an  index  to  select  a  segment  descriptor  In  the 
segment  table.  The  displacement  is  added  to  the  segment 
starting  address  to  produce  the  physical  address  of 
tne  operand  being  referenced,  idditionaliy ,  displacement 
is  easily  checiced  by  the  hardware  to  ensure  that  the 
reference  does  not  exceed  tne  length  of  tne  segment. 


segment 


2 .  Structured  Mgmary 

Tne  Intel  432  nas  segmented  memory  wnicn  Is 
different  from  tne  segmented  memories  of  otner 
microcomputers  as  follows: 

1.  Tne  Intel  432  can  address  up  to  2**24  segments. 
Eacn  segment  can  be  up  to  2**16  bytes  long. 
Therefore,  the  total  virtual  address  space  Is 
2**40  bytes. 

2.  Tne  Intel  422  uses  a  two-step  mapping  process 
tnat  separates  segment  relocation  and  access 
control . 

For  these  reasons  Intel  refers  to  tne  432's  memory  as 
structured  memory. 

Two-Step  Mapping:  The  access  mapping,  being  similar 
to  one-step  segment  mapping  process,  is  Illustrated  In 
Figure  3.11  and  It  Is  performed  as  follows: 


1.  The  segment  selector  part  of  a  logical  address 
Is  used  as  an  index  into  tne  access  segment  to 
select  one  of  the  access  descriptors,  which 
contain  access  rights  data. 

2.  The  access  descriptor  then  acts  as  an  index  into 

the  segment  table  to  select  a  segment 

descriptor. 

3.  The  displacement  is  added  to  the  segment 

starting  address. 


Although  there  are  several  segment  types,  the  two 
fundamental  types,  called  base  types,  are  tne  data  segments 
which  contain  both  data  and  instructions,  and  the  access 
segments,  wnicn  contain  only  access  descriptors.  Bacn  base 
type  is  divided  into  several  nardware  recognized  system  .pa 
types.  For  example,  data  segments  are  divided  into 
Instruction  segments  and  stacic  segments. 
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Figure  3.11  Two-Step  Mapping. 


Since  two-step  mappin*  process  separates  segment 
relocation  from  access  control,  tne  type  Information  Is 
contained  in  the  segment  descriptor  wnile  the  access 
Information  Is  contained  in  tne  access  descriptor.  This 
organization  allows  tne  division  of  protection  into  user- 
specific  protection  (access  riehts)  and  segment -spec if lc 
protection  (segment  type  protection). 

Each  program  module  is  supplied  at  run-time  with  a 
collection  of  segment  numoers  for  only  those  segments  it 
needs  to  access  durine  execution.  These  segments  determine 
the  access  environment  and  they  are  stored  in  a  collection 
of  access  segments. 

The  advantages  one  can  view  in  the  two-step-mapping 
can  be  summarized  as  follows: 


1.  It  takes  fewer  bits  in  an  address  to  specify  a 
segment  (as  few  as  four  bits). 

2.  It  restricts  tne  number  of  segments  accessible 
by  a  *lven  program. 

3.  It  separates  the  protection  features  into  access 
and  type  protection. 


One  potential  problem  with  the  two-step  mapping  is 
the  access  time.  To  speed  up  tne  process,  Intel 
maintains  an  associative  cache  that  stores  recently  used 
segment  descriptors,  access  descriptors,  and  the  addresses 
of  a  number  of  commonly  accessed  items. 
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la  either  the  single  or  the  multiuser 

environment  objects  need  protection  from  the  user  vno  might 
Inadvertently  use  an  object  in  a  way  that  it  was  not 
intended  to  be  used  and  from  programs  that  might  destroy  the 
object.  Additionally,  la  a  multiuser  environment  wnen 
several  users  require  simultaneous  access  to  the  same 
object,  at  least  two  more  problems  can  arise: 

1.  Access  Rights:  Not  all  the  users  need  to  have 
tne  same  access  rights. 

2.  Bxclusive  access:  One  user  may  require 

exclusive  access  to  that  object  for  a  particular 
operation  to  ensure  that  no  otner  urocessor 
alters  the  object  wnlle  tne  operation  proceeds. 

These  problems  are  solved  in  tne  432  architecture  by 
tne  use  of  tne  access  descriptors. 

4 *  Access  Descriptors 

Eacn  object  nas  its  own  access  descriptors  vnicn 
act  as  botn  prlviiedge  and  protection  permits  for  the 
object.  Many  access  descriptors  can  exist  for  the  same 
object.  Each  access  descriptor  belongs  to  some  (but  may  be 
copied  and/or  passed  to  another)  procedure  (context),  and 
defines  tne  access  rights  or  the  procedure  using  this 
object.  A  procedure  can  reference  a  segment  of  memory  if  and 
only  it  it  holds  an  access  descriptor  for  that  segment.  Tne 
basic  rights  accorded  the  procedure  by  the  access  descriptor 
can  be  read  only,  write  only,  both  or  none. 
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An  object  can  be  a  contiguous  subsection  of  a 
segment  or  it  can  consist  of  a  single  segment,  or  collection 
of  segments.  Figure  3.12  illustrates  tne  relation  between 
segments  and  objects. 

Tne  term  segment  refers  to  tne  physical 
structure  of  tne  data  in  memory  while  the  term  object  rerers 
to  tne  logical  structure  of  tne  data  in  memory.  Viewing  an 
object  as  a  single  entity,  its  root  segment  specifies  tne 
beginning  of  the  object  while  the  descriptor  segment  that 
points  to  this  root  segment  is  considered  as  pointing  to  tne 
whole  object.  Such  a  segment  descriptor  is  called  ooject  .pa 
reference,  while  tne  segment  table  containing  object 
references  is  called  object  table. 
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Fieure  3.12  Relation  among  Objects  and  Segments. 


F.  OPERATING  SYSTEM 

Tne  unique  item  in  tne  432  arcltecture  is  tne  way 
its  operating  system  is  implemented.  Tnere  are  two  distinct. 
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not  self-complete  but  cooperating,  operating  systems;  one  is 
implemented  in  hardware  and  is  called  tne  Silicon  OS,  -wciie 
the  other  is  a  collection  of  Ida  packages  available  to  the 
user  for  further  modification  as  required,  and  called  tne 

iMAX  OS.  Figure  3.13  illustrates  the  mechanisms  implemented 
in  tne  Silicon  OS  and  tne  cooperating  iMAX  OS  as  wen  as  tne 
conventional  architecture  level  and  the  user  interface 
level . 


USER  INTERFACE  TO  432 
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Figure  3.13  Silicon  and  iMAX  OS's. 


1.  The  Silicon  OS 

A  number  of  resource  management  mechanisms  are 
implemented  in  tne  nardwar'  ,  while  tne  resource  managment 
policies  are  established  oy  software  in  iMAX  OS.  These 
mecnanlsms  are  wnat  Intel  calls  tne  Silicon  OS,  whlcn 
consists  of  a  memory  resources  manager  and  processor 


resources  manager.  Tne  mecnanlsms  supported  by  toe  Silicon 
OS  are  illustrated  in  figure  3.13. 

2 .  iMAX  OS 

The  iMAX  OS  is  a  collection  or  Ada  pacfcages  provided 
in  two  different  subsystems.  Tne  users  can  select  tne  one 
best  tailored  to  their  applications: 

a.  Full  iMAX  provides  run-time  support  including 
dynamic  storage  management,  dynamic  process 
management,  and  I/O  interface. 

b.  Minimal  iMAX  is  a  subset  of  full  IMAX  and 

supports  the  execution  of  multiple  processes 
on  a  multiprocessor  environment.  It  does  not 

support  dynamic  storage  and/or  proress 
management  and  I/O  except  tnrough  tne  DEBUG- 
432  debugger. 

Tne  only  compiler  that  generates  code  for  tne 

432  is  the  Ada  compiler  provided  by  Intel.  Although  this 
forces  programmers  to  use  only  tne  Ada  language  for  writing 
programs  running  under  tne  432,  it  allows  tnem  to  mane  easy 
calls  to  the  iMAX  pacnages  by  using  tne  Ada  provided 

facilities,  sucn  as  tne  environment  pragma,  with  clause  and 
use  clause. 

Two  Kinds  of  processes  can  be  controlled  by  iMAX; 

the  static  processes  whicn  are  created  by  the  user  at 

system  initialization  and  tne  dynamic  processes  which  are 
created  dynamically  by  the  system  and  then  entered  into  tne 
ready  state.  The  minimal  iMAX,  which  does  not  support 
dynamic  operations,  requires  only  47K  of  memory  compared  to 
290X  for  tne  full  IMAX. 


The  iMAX  pacicaees  manage  and  enfiance  tfte  432 's 
Interprocess  communication,  data  transfers  between 
peripneral  devices  and  the  432  central  system,  and  allows 
the  users  to  configure  and  control  a  number  of  General  Data 
Processors  and  Interface  Processors,  static  user  processes, 
and  I/O  device  interfaces. 

G.  PROGRAM  STRUCTURE 

In  most  computer  systems  program  structure  is  part  of 
the  operating  system  or  tne  language  run-time  environment 
and  there  is  no  need  for  tne  program  structure  to  be 
Included  in  tne  description  of  tne  architecture.  However,  in 
tne  Intel  432,  the  program  structure  is  part  or  the 
arcnltecture  and  contains  tne  following  objects: 

1 .  Processor  Objects 

2.  Process  Objects 

3.  Context  Objects 

4.  Instruction  Objects 

5.  Data  Objects 

1  •  Processor  OpJ.£ct 

A  previous  section  specified  that  tne  processors  in 
a  multiprocessor  environment  are  hardware-recognized 

objects  and  tnat  object  is  a  data  structure  in  memory.  It 
is  logical  therefore  to  as*  how  oan  a  GDP,  made  of  silicon 
and  sitting  on  a  pc  hoard,  where  it  fetches  and  executes 
instructions,  be  a  data  structure  in  memory? 

The  physical  processor  is  not  an  object.  However, 
each  physical  processor  does  nave  an  object  (a  data 


structure  in  memory)  associated  with  it  which  is  called  a 
processor  object.  The  processor  object  is  an  abstract 
representation  of  the  GDP  and  is  in  one-to-one 
correspondence  with  the  GDP.  It  can  reside  anywhere  in  the 
memory  and  can  be  dynamically  relocated  if  necessary. 
Addressed  by  its  associated  processor  via  an  on-cnip 
reference,  the  processor  object  provides  the  means  to  assign 
tne  processor  it  represents  to  a  particular  process  set.  It 
also  serves  to  record  information  about  the  physical 
processor  such  as  its  state  (running  or  halted),  diagnostic 
information  and  references  for  otner  objects  tne  processor 
needs.  Additionally,  it  contains  an  object  reference  for  the 
process  object  currently  running  on  the  processor.  Tnis 
reference  changes  in  time  as  tne  processor  switches  among 
different  processes.  Tne  processor  object  is  depicted  in 
Figure  3.14  with  the  operations  which  act  upon  it. 

Remember  that  the  GDP  is  a  tnree  stage  pipeline 
processor  whicn  consists  of  two  cnips,  eacn  one  of  wnicn  nas 
two  subprocessors.  If  the  programmer  tries  to  Keep  all  of 
tnese  details  in  mind  as  well  as  tne  flow  of  information  and 
the  lata  manipulation,  while  writing  a  program  statement, 
complexity  and  confusion  will  reign.  However,  if  the 
programmer  considers  that  a  processor  exists  which  can 
perform  a  set  of  operations,  programming  is  simpler. 


2  *  El2£§ss  0  b  j.e  e  t£ 

A  process  is  a  locus  of  control  within  an 
instruction  sequence.  Tnat  is,  a  process  is  tne  abstract 


Send  to  processor- - (inst) - > 

Broadcast  to - (inst) - > 

processor 

Read  processor - (inst) - > 

status  and  cIock 

Requalify  process - (nard ) - > 

Select  processor - — (nard ) - > 

Start  processor-— — (narl) - > 

Create  processor - (soft) - > 

object 

Legend:  inst  =  operation  is  a  machine  instruction 

(operator) . 

narl  *  operation  is  performed  by  nardware  as 
a  result  of  conditions  detected  by 
tne  processor. 

soft  =  operation  may  be  implemented  by 

software  (e.e.  an  operating  system'. 

Figure  3.14  Processor  Object. 

entity  wnicft  moves  througn  tne  Instructions  of  a  procedure 
as  the  procedure  is  executed  by  tne  processor.  Given  this 
definition  for  a  process  object,  now  can  a  sequence  of 
operations  be  an  object?  Tne  process  is  not  an  object,  out 
each  process  does  nave  an  object  associated  with  it  wnicn  is 
called  a  process  object.  Tne  process  object  contains 
information  concerning  now  tne  process  snoula  be  scheduled 
and  wnat  is  tne  process  status  (running,  waiting,  etc.). 

E>7 


processor 
o  bject 


The  significance  of  tne  existence  and  the  use  of 
tne  object  reference  is  tnat  tne  432's  object  oriented 
addressing  and  protection  mechanism  does  not  allow  a 
processor  to  access  an  object  unless  it  has  an  object 
reference  for  it.  The  object  reference  from  tne  processor 
object  to  the  process  object  changes  dynamically  in  time  as 
the  processor  switches  among  different  processes.  Each 
process  has  its  own  process  object.  The  processes  may  snare 
tne  same  processor.  Figure  3.15  indicates  operations  on  a 
process  object. 


read  process  clocx - — (lnts) - > 

enter  global  segment - (  ins t ) - > 

get  state  information - (hard) - > 

save  state  information - (hard) - > 

dispatch  process - (hard) - > 

set  scheduling  parameters - (soft) - > 

create  process  object - (50ft) - > 

Figure  3.15  Process  Object 

3 •  Context  0 b.l££ii 

Procedures  (e.g.  SOOAREROOT  X  )  are  snared  among 
several  different  processes  by  giving  eacn  process  a  copy 

(an  instance)  of  the  procedure.  Eacn  instance  of  a  procedure 
(eacn  copy)  is  called  a  context. 


process 

object 
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A  context  object  contains  information  about  a 
particular  Invocation  of  a  procedure.  Tnis  means  tnat  tnere 
are  as  many  context  objects  for  tne  same  procedure  as  tnere 
are  invocations  of  tne  procedure.  Tne  Information  tnat  a 
context  contains  includes  tne  Instruction  pointer  for  tnis 
context,  tne  stacx  pointer  for  tnis  context's  staclr,  the 
return  lint  to  the  calling  context,  and  references  for  all 
tne  objects  tnat  can  be  accessed  by  tnis  context. 

Figure  3.16  depicts  a  context  object  and  tne 
operations  vnicn  act  upon  It.  Tne  complete  list  of  objects 
currently  accessible  by  tne  procedure  is  called  its  access 
environment.  The  432's  object-oriented  protection  mechanism 
does  not  allow  a  program  to  access  an  object  unless  it  nas  a 
reference  for  tnat  object.  Tnus  in  tne  context  one  can  only 
access  objects  tnat  are  listed  in  tne  access  environment, 
and  tne  access  environment  cnanges  only  if  tne  current 
context  calls  another  procedure  because  tne  called  procedure 
nas  a  different  context  and  nence  a  different  list  of 
objects  tnat  can  be  accessed.  This  places  the  protected 
access  environment  at  tne  procedure  level,  instead  of  tne 
process  or  Job  level  as  on  most  systems. 

4.  In'trucll on 

An  instruction  object  nas  two  major 
characteristics: 

1.  It  can  only  nold  Instructions  (and  a  little 
bit  of  system  information)  and  never  lata. 


2.  It  is  tne  only  type  of  object  taat  a 
processor  will  use  as  a  source  of 

Instructions  to  be  fetched  and  executed. 


> ! 
i 
i 

>i  context 

i 

i 

>! 

!  object 

> ! 
i 
i 

> ! 
i 
i 

> ! 
i 
i 

> ! 


Figure  3.16  Context  Object. 

This  second  feature  implies  tnat  the  432's 
object-oriented  protection  mecnanism  will  never  allow  any 
other  kind  of  object  (proccess  object,  data  ooject,  etc.)  to 
be  accidentally  mistaken  for  instruction  and  thus  executed. 
This  isolation  of  tne  instructions  provides  tne  advantage 
that  all  432  programs  are  fully  reentrant. 

Instruction  objects  can  be  snared  by  several 
instances  of  a  program.  Figure  3.1?  Indicates  an  instruction 
object  and  tne  operations  vnicn  act  upon  it. 

5.  Dili  0£,li£li 

Data  object  is  in  ooject  tnat  colds  data  (e.g. 
integers,  reals,  character,  tables,  etc.).  Tne  432  provides 
a  mechanism  for  assigning  lata  objects  (as  well  as  other 


Call - - — (ins t ) - 

Call  with  message- — (inst) - 

Return - ( inst ) - 

Create  context - (inst) - 

object 

Create  context - (hard) - 

data  segment 

Create  operand - (nard) - 

stack 

Destroy  context - (nard) - 

Garbage  collection - (soft) - 
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objects)  a  software-defined  type.  Tnis  is  anotaer  protection 
mechanism  waicn  ensures  tnat  tne  object  will  oe  manipulated 
by  Instructions  of  tne  proper  type. 


Call  context - (Inst) — > 

Call  context - - (Inst) — > 

with  message 

Return  - — — - (last)— > 

Branch  intersegment - (Inst) - > 

Branch  intersegment - (last) - > 

and  llnic 

Branca  intersegment - (Inst) - > 

without  trace 

Execute - (flard  ) - > 

Create- - - - (soft) - > 

Figure  3.1?  Instruction  Object. 

5.  Summary  of  tne  Structure  of  a  Program 

Fleure  3. IS  summarizes  the  important  points 
about  eacn  object  of  tne  program  structure. 

H.  INTERPROCESS  COMMUNICATION 

It  has  been  said  that  one  of  the  salient  characteristics 
of  the  432  is  its  capability  to  support  multiprocessing  in  a 
multiprocessor  environment.  In  other  words  the  system 
provides  for  concurrent  programming.  The  mechanisms  that 
support  concurrent  programming  are  quite  complex  and  include 
the  use  of  Communication  Ports  Objects,  Domain  Objects,  and 
Dispatching  Port  Objects.  Following  an  explanation  of  these 
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TFrocessorT 


Memory 
Space 


'.Processor! 
i  Object  ! 


!  Process  ! 
!  Object  ! 


!  Context  ! 
Object  ' 


Instruction ! 

I 
I 


Object 


Object 


Pnysical  Processor 
-Made  of  Silicon  (not 
-Fetches  and  Executes 


an  object) 
Instructions 


Processor  object 

-Eacn  processor  has  one 

-Gontains  information  sucn  as: 

-Processor  status  (ee,  running,  nalted) 
-Diagnostic  and  macnine  cnecic  informat. 
-Reference  for  the  process  currently 
being  executed 


Process  Object 

-One  for  each  process  in  tne  system 
-Contains  information  sucn  as: 

-Process  status  (eg,  running,  halted) 
-How  tne  process  should  be  scneduled 
-Reference  for  tne  context  currently 
being  executed 


•  _  i 


Context  Object 

-One  per  eacn  instance  of  a  procedure 
-Contains  information  sucn  as: 

-Instruction  pointer  for  tnis  object 
-StacK  pointer  for  tnis  context's  stacic 
-Return  Unit  to  the  context's  stacx 
-Reference  for  ail  tne  objects  that  can 
be  accessed  by  tnis  context 


Instruction  Object 

-Contains  only  instruction  and  no  data 
-It  is  the  only  type  or  object  tnat  a 
processor  uses  as  a  source  of 
instructions  to  be  fetched  and 
executed 


are  tne  hardware  recocnized  objects 

i 


Data  Object 

-Contains  Data  (eg,  integers, 
characters  or  a  combination 
primitive  data  types) 


reals , 
of  several 


Figure  3.18  Summary  of  the  Program  Structure. 
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objects,  a  simplified  erample  will  oe  presented  for  a 
general  understanding  of  tne  mecnanism  tnat  supports 
concurrent  programming. 

1 .  Communlca  ti on  Port 

A  communication  nort  is  tne  communication  medium 
between  two  asyncaronously  communicating  processes.  Eaen 
communication  port  is  represented  oy  an  object  wnicn 
contains  information  on  messages  tnat  are  sent  to  processes. 
Figure  3.19  indicates  operations  on  a  communication  port 
object. 


Send - - - ( inst 

Conditional  send - —(Inst 

Surrogate  send - (inst 

Receive— - - - ( inst 

Conditional  receive - (inst 

Surrogate  receive - (inst 

Message  buffer - - - ( narl 

full  cnecit 

Enqueue  message - (ftard 

Enqueue  carrier — - —(hard 

to  port 

Create  port - - (soft 

Priority  message - - (soft 

enqueue 

Multiple  wait - (soft 


communication 

port 

object 


Figure  3.19  Communication  Port  Object 
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The  communication  ports,  by  acting  as  a  buffer 
between  two  asynchronous  processes,  allow  each  process  to 
proceed  at  its  own  rate. 

2 .  Domain  Objects 

Inbedded  in  the  features  of  Domain  Objects  are  the 
concepts  of  static  and  dynamic  objects.  Tne  concept  of 
dynamic  objects  has  been  already  encountered  in  Section  G.3, 
wnere  the  context  objects-  are  examined.  Recall  that  the 
access  environment  consists  of  oojects  for  wnicn  an  object 
reference  exists  in  the  list  of  the  current  context  object. 
Additionally,  tne  access  environment  cnanges  dynamically 
when  a  procedure  is  called  by  a  context  and  the  access 
environment  is  now  tne  list  of  the  new  current  context. 
Since  the  objects  accessible  by  the  process  cnange 
dynamically  in  time,  the  oojects  pointed  to  by  tne  current 
conteit  object  vary  in  time.  Therefore  tne  space  they  occupy 
in  memory  is  deallocated  once  tney  are  not  accessible  by  the 
proccess.  Hence  these  objects  are  dynamic  oDjects.  In 
contrast  static  objects  are  those  whose  memory  space  is 
never  deallocated  regardless  of  wnetner  they  are  accessible 
or  not.  In  summary,  a  context  object  is  also  a  list  of 
dynamic  objects  wnile  a  domain  is  a  list  of  object 
references  for  ail  tne  static  oojects  used  by  a  module. 

In  tne  object-oriented  decomposition  metnod,  tne 
criterion  for  modularization  is  for  eacn  module  to  hide  a 
desien  decision.  In  order  to  carry  out  its  tasx,  a  module 


mignt  consist  of  more  tnan  one  procedure  wnlcn  In  turn  mignt 
need  to  access  some,  ail  or  none  of  the  static  objects  used 
by  tne  module.  Tnis  is  tne  reason  a  domain  contains  a  list 
of  object  references  to  all  static  objects  of  tne  module. 

Tne  reason  objects  associated  with  tne  modules 
are  called  domains  Is  tnat  tne  module  tney  represent  confine 
knowledge  of  tne  object  structure  witnin  a  specified  domain. 
Figure  3.20  depicts  a  domain  object  and  tne  operations  wnicn 
act  upon  it. 


Call  context - (inst) - > 

Call  context - (inst) - > 

with  message 

Return - (inst) - > 

Create  context - (hard) - > 

Create  domain — - — - (soft) - > 

Figure  3.20  Domain  Object. 

Networks  of  domains,  wnere  eacn  domain  nines  tne 
representation  of  an  object,  represent  tne  static  structure 
of  a  432  proeram.  Some  of  tne  domains  make  use  of  objects  in 
other  domains  in  the  network  to  create  a  more  complex 

object . 

If  a  module  (represented  by  a  domain  object) 

needs  to  use  procedures  provided  by  anotner  module,  tne 

first  module  must  nave  a  reference  for  tne  domain  tnat 

represents  tne  second  module,  Tne  domains  can  be  viewed 


domain 

object 


65 


either  from  an  outside  or  inside  point  of  view.  Consequently 
procedures  can  be  executed  inside  or  outside  of  tne  domain, 
this  prevents  static  objects  of  tne  domain  from  Dein* 
accessed  by  ail  procedures  tnat  use  tais  domain. 

In  this  case  tne  static  objects  are  divided  as 

follows : 

X.  Private  objects  -  accessible  only  by 
procedures  inside  tne  domain. 

2.  Public  objects  -accessible  by  procedures 
botn  inside  and  outside  tne  domain. 

Let  us  assume  the  situation  where  a  procedure 
(of  a  module)  is  currently  executing.  This  procedure  uses 
tne  same  domain  object  wnicn  represents  tne  module  tnat 
belongs  to  the  procedure.  In  this  case  we  say  the  procedure 
is  executing  inside  tne  domain.  Tne  same  procedure  needs  to 
mate  a  call  to  another  procedure  not  belor.*in*  to  its 

module.  For  tnls  to  be  achieved  tne  first  module  must  nave  a 
reference  to  the  domain  representing  tne  module  of  tne 

callee.  After  tnis  object  reference  Is  established  tne 

caller  can  use  the  static  objects  only  in  tne  public  domain 
of  tne  callee.  In  tnis  case  tne  procedure  is  executing 
outside  tne  domain. 

3.  DispaicSiHS  Efill 

Tne  dispatching  port  object  consist  of  two 

queues  tnat  serve  to  matcn  processes  witn  processors.  It  is 
the  object  tnat  is  used  to  implement  transparent 
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A 


multiprocessing.  Figure  3.21  Indicates  a  dispatcnine  port 
object  and  tne  operations  wnicn  act  upon  it. 


Dispatching  port - (nard) - > 

Scneduie  process - (nard) - > 

object 

Enqueue  processor - (nard) - > 

ob jec t 

Create  dispatching - (soft) - > 

port 

Figure  3.21  Dispatching  Port  Object 

4.  Example  of  Interprocess  CfimQuni gallon 

Consider  a  program,  CHAT,  which  consists  of  two 
subprograms  TED  and  JOHN.  Program  TED  writes  a  report  and 

then  sends  it  to  program  JOHN  to  type  it  whicn  in  turn  sends 

it  bacfc  to  TED  for  proofreading.  Vnen  tne  report  is  correct 
TED  prints  it. 

Tne  subprograms  TED  and  JOHN  will  be  tne  two 
processes  of  CHAT  wnicn  can  start  execution  independently  in 
two  different  processors  of  tne  system.  For  simplicity  let 
us  consider  tnat  TED  starts  execution  first  and  begins  to 
write  its  report,  tfnen  it  is  finisned,  JOHN  nas  been 

executing  and  it  is  ready  to  recieve  TED's  report  for 

typing. 

Tne  mechanism  for  sending  tne  report  from  TED  to 
JOHN  is  tne  communication  port  wnicn  acts  as  a  buffer 
between  tne  two  asynchronous  processes,  allowing  each  to 
proceed  at  its  own  rate.  Two  communications  ports  are  needed 


dispatching  ! 
port  ! 

j  object  j 

1  I 


for  our  example.  One  is  TED's  receiver  and  JOHN'S 
transmitter  wnlie  tne  otner  is  JOHN'S  receiver  ana  TED'S 
transmitter.  Figure  3.22  illustrates  tne  communication 
between  TED  and  JOHN. 


!  draft  \ 
!  reports  / 


!  TED's  ! 
!  object  ! 


/ - 

/  typed  ! 
\  reports  ! 


COMM.  \ 


TED's 
receiver 

PORT  / 


/  COMM. 

/  JOHN'S  ! 
\  receiver  ! 

\  PORT 


\  - \ 

\  i  draft  \ 
/  i  reports  / 
/ 


!  JOHN'S  ! 
!  object  ! 


/ - 

/  typed  ! 
\  reports  ! 


i 

i 


Figure  3.22  Interprocess  Communication 


Tne  processes  TED  and  JOHN  interchange  messages 
via  tne  communication  ports  and  tne  operations  SEND  and 
RECEIVE  defined  on  tne  communication  port  object  bear  tne 
burden  of  tnat  intercommunication. 

The  instruction  SEND  aas  two  operands.  One  is 
tne  message  itself  and  tne  otner  is  tne  communication  port 
where  tne  message  is  being  sent.  Before  tne  SEND  is  executed 
tne  process  nas  a  message  it  wants  to  send.  After  SEND  is 
executed,  the  message  nas  been  sent  to  the  specified 
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communication  port.  For  efficiency,  only  the  object 
reference  is  copied. 

Tne  RECEIVE  instruction  nas  one  operand,  tne 
communication  port  wnere  tne  message  is  to  be  received. 
Before  RECEIVE  is  executed  there  is  a  message  waiting  in  the 
communication  port.  After  RECEIVE  is  executed,  tne  message 
is  moved  from  tne  port  to  tne  process  executing  tne  RECEIVE. 
Again  only  tne  object  reference  is  copied.  In  tne  case  a 
RECEIVE  instruction  is  executed  witnout  a  message  in  tne 
communication  port,  tne  process  waits  until  a  message  is 
sent . 

I.  A  BASIC  I/O  10DEL 

Anotner  complicated  mecnanism  in  tne  432  arcnitecure  is 
tne  I/O  operation.  Here  we  examine  tne  Dasic  means  for 
performing  an  I/O  operation  as  well  as  tne  very  basic 
Implementation  mecnanisms  needed  for  I/O  operations. 

A  peripheral  subsystem  is  an  autonomous  computer  system 
witn  its  own  local  memory,  I/O  devices  and  controllers,  at 
least  one  processor,  and  software.  Tne  number  of  peripheral 
subsystems  employed  in  any  given  application  nay  be  varied 
with  changing  needs,  independent  of  tne  number  of  GDPs  in 
tne  system. 

To  support  tne  transfer  of  data  through  tne  wall  that 
separates  a  peripheral  subsystem  from  tne  main  system,  tne 
Interface  Processor  (IP)  provides  a  set  of  software- 
controlled  windows.  A  window  is  used  to  expose  a  single 


object  la  main  system  memory  so  tnat  its  contents  nay  be 
transferred  to  or  from  tne  peripneral  subsystem. 


Main  System 


*>!  Process  { 


{Service  Reply! 
!  Message  i 


iService  Requested! 


Message 


Peri  pneral 

Subsystem 

Interface 


.'Service  Reply! 
!  Message  ! 


IService  Requested! 
Message  ! 


■!  Device  Interface  !<- 


!  I/O  ! 


Peripneral  Subsystem 


Figure  3.23  Peripneral  Subsystem  Interface. 


Tbe  IP  also  provides  a  set  of  functions  tnat  are  invoked 
by  software.  Tney  generally  permit  objects  in  main  system 


memory  to  be  manipulated  as  entities,  and  enable 
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communication  between  main  system  processes  and  software 
executing  in  a  peripnerai  subsystem.  Figure  3.23  snows  tne 
peripheral  subsystem  interface. 

A  device  interface  is  considered  to  be  tne  hardware  and 
software  in  tne  peripnerai  subsystem  tnat  is  responsible  for 
managing  an  I/O  device.  A  message  sent  from  a  process  that 
needs  an  I/O  service  contains  information  tnat  describes  tne 
requested  operation  (e.g.  "read  file  XYZ").  The  device 
interface  interprets  the  message  and  carries  out  tne 
operation.  If  an  operation  requests  input  data,  tne  device 
interface  returns  tne  data  as  a  message  to  tne  originating 
process.  Tne  device  interface  may  also  return  a  message  to 
positively  acknowledge  completion  of  a  request. 

Tne  IP  is  connected  to  tne  peripnerai  subsystem  bus  as 
if  It  were  a  memory  component;  it  occupies  a  block  of  memory 
addresses  up  to  64K  bytes  long.  Figure  3.24  illustrates  the 
peripnerai  subsystem  nariwars. 

The  Attached  Processor  (AP)  and  the  IP  interact  with 
eacn  otner  by  means  of  address  references  generated  by  tne 
AP  and  interrupt  requests  generated  by  tne  IF.  At  any  given 
time,  tne  IP  controller  is  represented  in  main  memory  by  a 
process  object  and  a  context  object.  Like  a  GDP,  tne  IP 
itself  is  represented  by  a  processor  object. 

When  supporting  multiple  process  environments,  the  IP 
controller  selects  tne  environment  in  wnicn  a  function  is  to 
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tie  executed.  If  an  error  occurs  while  tfle  IP  controller  Is 
executing  a  function  on  benalf  of  one  device  interface,  tnat 
error  is  confined  to  tne  associated  process,  and  processes 
associated  with  ottier  device  interfaces  are  not  affected. 

I,  WINDOWS 

Every  transfer  of  data  between  tne  main  system  ana  a 
peripheral  subsystem  is  performed  with  tne  an  of  an  IP 
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window.  A  window  defines  a  correspondence,  or  mapping, 
between  a  subrange  of  perlpneral  subsystem  memory  addresses 
witbln  the  ranee  of  addresses  occupied  by  tne  IP  and  an 
object  in  main  system  memory. 

The  action  of  the  IP,  In  mappine  the  peripheral 
subsystem  address  to  tne  main  system  object.  Is  transparent 
to  the  agent  matting  the  reference?  as  far  as  It  is 
concerned,  it  Is  simply  reading  or  writing  local  memory. 
Since  a  window  is  referenced  ilice  local  memory,  any 
Individual  transfer  may  be  between  an  object  and  local 
memory,  an  object  and  a  processor  register,  or  an  object  and 
an  I/O  device. 

There  are  four  IP  windows  that  may  be  mapped  into  four 
different  objects.  The  IP  controller  may  alter  tne  windows 
during  execution  to  map  different  subranges  and  objects.  A 
fifth  window  provides  the  IP  controller  with  access  to  the 
IP's  function  facility.  By  writing  operands  and  an  opcode 
Into  predefined  locations  in  this  window's  subranee,  the  IP 
controller  requests  the  IP  to  execute  a  function  on  its 
behalf.  Upon  completion  of  the  function,  tne  IP  provides 
status  information  that  the  IP  controller  can  read  tnrough 
tne  window. 

Since  there  is  a  finite  number  of  windows,  most 
applications  will  need  to  manage  tnem  as  scarce  resources 
that  will  not  always  be  instantly  available.  This  means  tnat 
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at  least  some  I/O  device  transfers  will  nave  to  be  buffered 
In  local  memory  until  a  window  becomes  available. 

L.  TRANSPARENT  MULTIPROCESSING 

Tne  Intel  432  is  especially  designed  to  support  parallel 
execution  of  programs  by  multiple  processors.  Absolutely  no 
software  changes  are  required  to  move  programs  from  single 
processor  systems  to  multiple  processor  systems  or  vice 
versa . 

Tne  first  advantage  of  transparent  multiprocessing  is 
flexibility  provided  by  a  macnine  tnat  o  fers  a  ranee  or 
performance.  Processors  can  be  added  to  or  removed  from 
tne  conf leuration  to  meet  tne  desired  performance  or  price. 
Tne  second  advantage  is  reliability,  because  if  one 
processor  falls,  the  rest  of  tne  system  may  be  able  to 
continue  running.  In  fact,  during  a  bencnmarir  performance 
test,  one  slot  in  tne  system  motnerboard  prevented  an 
assigned  GDP  from  being  initialized  and  tne  system  continued 
to  execute. 

l •  Tne  Three  Stages  £r ocessor  Management 

Tne  effective  management  of  multiprocessing  in  a 
multiprocessor  environment  requires  Policy  Maxing, 
Scheduling,  and  Dispatcnlng. 

a.  Policy  Maxing 

Policy  Maxing  estabiisnes  tne  criteria  tnat 
determines  now  processes  snare  processors.  These  criteria 
are  defined  by  tne  user,  via  tne  1MAI  OS,  at  system's 
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initialization.  Tfie  iMAX  OS  passes  this  information  to  tfte 
Silicon  OS  for  Implementing  tne  policy  mecnanism. 

Options  tftat  can  be  selected  to  implement 
processor  snaring  are  first  -  come  -  first  -  serve  (FIFO), 
round  robin,  priority,  and  deadline  weighted.  Tne  user  can 
select  tne  one  which  meets  tne  applications  reauirements . 

Tne  Policy  Malting  requires  tne  user  to  set 
tne  scheduling  parameters  by  answering  questions  sucn  as:  By 
when  must  the  process  be  completed?  How  long  does  a  process 
execute  on  tne  processor?  flow  many  turns  can  a  process  nave 
before  terminating? 

b.  Scheduling 

Scheduling  is  tne  ordering  of  processes  to 
run  on  processors  in  a  manner  that  realizes  tne  policy.  It 
is  part  of  the  mecnanism  that  carries  out  the  policy. 

A  process  is  scnedulea  by  sending  tne 
process  to  the  dispatching  port  in  the  form  of  a  message 
object.  Once  In  tne  queue,  tne  process  waits  for  a  processor 
for  execution. 

c.  Dispatching 

Dispatching  is  the  assignment  of  processes 
to  processors  in  the  order  in  wnicn  the  processes  nave  been 
scheduled . 

Tne  meeting  places  for  processors  and 
processes  are  tne  Dlspatcing  Ports  where  tne  the  processes 
stand  in  line  waiting  for  service  by  a  processor,  and 
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processors  go  when  they  need  a  process  to  execute.  Whenever 
a  processor  needs  a  process  to  execute,  it  simply  removes 
the  first  process  in  line  at  its  dispatcning  port  ana  begins 
to  execute  it. 

2.  DilBilcing  ? Q.115.  illi  E££££ltS  S.iru£lUI£ 

We  nave  seen  tnat  tne  dispatcning  port  objects  are 
closely  related  to  tne  processor  object  and  process  object 
whica  are  part  of  the  program  structure.  This  relation  must 
be  well  controlled  in  order  to  prevent  perturbation  of  tne 
program  structure. 

For  example  the  networx  required  to  perform  process 
scheduling  and  dispatching  is  complex.  To  Keep  tracK  of 
these  assignments  two  tnings  must  be  accomplished .  First,  in 
each  processor  object  tnere  is  a  object  reference  for  tne 
processor's  dispatcning  port,  wnicn  means  teat  eacn 
processor  has  only  one  dispatching  port.  This  information 
forces  a  processor  to  always  visit  tne  same  dispatcning 
port.  Second,  in  eacn  process  object  tnere  is  an  object 
reference  to  the  dispatcning  port  tne  process  is  allowed  to 
visit  and  thus,  a  process  can  visit  only  one  dispatcning 
port.  We  can  conclude,  therefore,  tnat  by  naving  one 
dispatcing  port  per  processor  and  process  tne 
multiprocessing  taslt  of  tne  432  can  be  accomplished  witnout 
major  effort  other  tnan  assigning  tne  proper  policy  maging 


parameters 


Tftls  chapter  has  presented  the  characteristics  and 
advantages  of  tne  Intel  432  over  conventlnai 
microprocessors.  Although  this  chapter  is  lone  and  at  times 
detailed,  it  presents  the  requisite  information  necessary  to 
understand  the  results  observed  in  the  Bencnmam  Performance 
Chapter. 
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I? .  mpitiprocessor/mdltiprocbss  benchmark  performance 

la  general  the  Benchmark  Performance  Test  was  conducted 
using  the  Benchmark  programs  generated  in  Applegate  [Ref. 
3J «  modified  as  required  to  execute  in  tne 
Multiprocessor/Multiprocess  environment.  Initially,  the  test 
was  conducted  witn  only  one  processor  and  one  process  in  tne 
system  to  confirm  the  results  reported  in  Applegate  IRef. 
3J .  Tnen,  using  the  same  3encnmark  Programs,  tne  test  was 
performed  with  two  processo r/processes ,  three 
processor/processes  and  finally  four  processor/processes  in 
the  system  to  determine  if  the  432/67(5  system  is  capable  of 
sustaining  incremental  performance  improvements  as 
processors  are  added  to  tne  system. 

A.  BENCHMARK  PERFORMANCE  TEST 

Kodres  [Ref.  12J  analyses  mul tiprocessor  systems  that 
uses  a  common  shared  memory.  Although  dependent  on  tne  type 
of  Instructions  being  executed,  it  was  shown  tnat  if  tne 
programs  are  fetched  from  common  memory,  the  systems  bus 
becomes  a  bottleneck  with  only  two  processors  in  tne  system. 
To  determine  if  the  INTEL  432/67(5  system  could  be  effective 
with  six  processors  as  reported  in  the  Intel  manual  [Ref. 
13]  ,  a  series  of  Benchmark  performance  tests  were  conducted 
using  seven  programs  from  the  Computer  Family  Architecture 
Study  (CFS)  (Figures  4.1  -  4.4),  two  programs  from  a 
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performance  comparison  conducted  by  me  University  of 
California  -  Berkeley  (Figure  4.5),  and  two  programs  tnat 
executed  instructions  at  opposite  ends  of  the  iAPX  432  bus 
activity  spectrum  (Figure  4.6).  All  Bencnmaric  programs  were 
executed  witn  tfte  operating  system  configured  for  the 
default  service  period  (DF)  and  again  with  the  service 
period  set  to  infinite  period  count  (IF).  Each  figure 
depicting  performance  contains  tae  name  of  the  Benchmark 
program,  tne  number  of  iterations,  and  tne  number  of  seconds 
required  to  complete  tne  execution  as  well  as  tne  curve 
snowing  maximum  tneoreticai  efficiency,  observed  performance 
for  tne  infinite  period  count  (IF),  and  default  (DF)  service 
periods.  Additionally,  calculated  efficiency  numbers 
associated  witn  eacn  system  configuration  are  included  on 
the  right  side  of  tne  graph  for  easy  reference. 

Each  program  was  executed  witn  tne  INTEL  432/67<i  system 
configured  for  one  processor.  A  second  processor  was 
installed  and  two  processes  containing  Identical  Bencnmarx 
programs  were  timed  during  execution.  Processors  and 

|  processes  were  added  incrementiaily  up  to  and  including  four 

( 

i  iAPX  432  General  Data  Processors  (GDP).  In  general  the  tests 

i  snow  tnat  tne  INTEL  432/670  system  was  still  performing  at 

i 

j  approximately  ninety  percent  efficiency  witn  four  processors 

in  tne  system. 

i 
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B.  RESULTS 

Since  Kodres  [Ref.  12J  predicted  serious  bus  contention 
at  two  processors  and  tne  observed  performance  Is  still  at 
approximately  ninety  percent  vita  four  processors  in  the 
system,  additional  analysis  was  performed  using  a  Logic 
State  Analyzer  to  observe  systems  bus  activity  wnlle 
executing  instructions  at  opposite  ends  of  tne  bus  activity 
spectrum.  Benchmark  programs  were  designed  and  implemented 
tnat  execute  tne  MOVCH  instruction  to  represent  tne  nign  end 
of  bus  use  density  and  DIVORD  to  represent  the  low  end  of 
bus  activity. 

Snoop  [Ref.  14],  considering  a  system  bus  widtn  of 
sixteen  bits  and  a  nign  transfer  speed,  predicted  tnat  tne 
MOVCH  instruction  would  taxe  10.4  microseconds  to  execute 
wnlle  the  DIVORD  would  require  29.6  microseconds.  Usinsr  the 
Logic  State  Analyzer  delay  function  and  triggering  on  a 
known  address,  a  series  of  proeram  executions  were  performed 
to  generate  a  bus  activity  snapshot  of  650  microseconds.  By 
counting  the  number  of  bus  access  cycles  and  tne  number  of 
execution  cycles,  the  relative  efficiency  of  tne  Intel 
432/570  computer  system  was  calculated  for  one  tnrougn  9 
processors  using  the  equation  derived  by  Xodres  IRef .  12] : 
Figure  4.7  depicts  tne  predicted  and  experimental  results 
for  the  MOVCH  and  DIVORD  instructions. 
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Re  =  (B  +  B)  /  (NB  +  I)  where  Re  =  Relative  efficiency 

B  *  Bus  activity  cycles 

B  *  Execution  Cycles 

I  *  System's  Bus  Idle 
Time 

N  =  Number  or  Processors 

To  determine  if  tne  lata  eatnered  during  tne  Bus 
Snapsnot  period  was  representative  of  tne  Bencnmars 
performance  executions,  tne  instruction  execution  times  are 
compared  in  Table  4.1.  Tnere  is  a  small  difference  in 
execution  times  measured  by  tne  bus  activity  snapsnot  as 
opposed  to  timing  tne  repeated  execution  of  tne  instruction. 
Since  tne  timing  is  accurate  to  tne  nearest  second,  tnis 
small  difference  can  be  attributed  to  measurement  error.  Tne 
larger  difference  between  Snoop  predicted  execution  tines 
and  measured  execution  times  can  be  attributed  to  an  overly 
optimistic  prediction  by  Snoop. 

From  tne  calculations  displayed  in  Figure  4.7,  systems 
executing  instructions  consisting  of  fdOVCH  would  begin  to 
saturate  tne  system's  bus  at  4.3  processors  wnile  DIVORD 
instructions  induce  tne  bottlsnecx  at  7.?  processors.  Since 
tne  execution  time  of  DIFORD  is  greater  tnan  MOVCH,  it 
follows  tnat  tne  predicted  bus  contention  snould  be  less  for 
tne  DI70RD  program  as  observed.  Since  tnese  instructions 
represent  bus  activity  at  opposite  ends  of  the  bus  activity 


spectrum,  it  appears  tnat  tne  Intel's  design  of  six 
processors  per  system  is  an  appropriate  cnoice. 

C.  ANALYSIS 

Tne  explanation  for  tnis  performance  improvement  over 
tnat  observed  in  otaer  Multiprocessor/Multiprocess  systems 
tnat  fetcn  programs  from  common  memory  is  tne  INTEL  432/670 
system  nas  a  32  bit  system's  bus.  Tne  32  bit  system's  bus 
nas  a  maximum  of  77  megabits  per  second  transfer  rate 
compared  to  about  12  megabits  per  second  for  a  typical  16 
bit  MULTIBUS  system's  bus.  Additionally,  tne  instruction 
formats  used  by  tne  1APX  432  processors  are  designed  to 
reduce  the  number  of  bytes  transferred.  Finally,  by  usin*  a 
byte  addressable  boundary  ratner  tnan  a  word  boundary,  tne 
number  of  bytes  that  must  be  transferred  when  a  processor 
fetcnes  instructions  is  reduced. 
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Figure  4.7  Predected  and  Actual  Processing  Performance 


Table  4.1  Instruction  Execution  Times  (Microseconds). 


INSTRUCTION 

432/570 

BUS 

SHOOP 

OBSERFED 

SNAPSHOT 

PREDICTED 

M07CH 

12.4 

12.6 

10.4 

DI70RD 

32.3 

32.1 

29.6 

V 


CONCLUSIONS 


Tfte  excessive  execution  overnead  resulting  from  the 
Intel  432  object  oriented  arcnitecture  nas  prevented  tne 
Intel  432  from  demonstrating  superiority  when  comparing  its 
speed  of  execution  to  otner  microprocessors  in  a 
Uniprocessor  environment  (ie.,  one  processor  with  its  own 
memory  and  systems  bus).  For  example  vnen  compared  vitn  tne 
Motorola  68000  and  tfte  INTEL  8086,  tfte  1APX  432  provided 
approximately  one-half  the  throughput  [PATTERSON) . 

Benchmark  performance  depends  neaviiy  on  -tne  Instruction 
set  being  executed.  Since  individual  systems  use  unique 
metnods  of  performing  certain  operations,  average  Bencnmarx 
figures  could  be  misleading  if  the  system  was  to  be  designed 
for  a  specific  application.  For  example,  if  the  instruction 
set  required  was  predominately  Floating  Point  operations, 
the  INTEL  432  performance  should  be  superior  oecause  of  its 
efficient  Floating  Point  nardvare. 

rfhen  comparing  a  computer's  ability  to  perform  in  a 
Multiprocessor  environment,  instruction  mix  is  still 
important  but  you  must  also  consider  tfte  bandwidth  of  the 
memory.  Tnere  are  three  types  of  Multiprocessor 
architectures  that  effect  the  bandwidth  characteristics  of 
Multiprocessor  systems: 
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1.  Program  and  data  stored  In  global  memory  where 
all  processors  nave  equal  access. 

2.  Program  stored  In  a  local  memory  Isolated  to 
access  only  by  tne  parent  processor.  Data  would 
be  stored  in  global  memory. 

3.  Same  as  system  2  except  local  memories  are  also 

accessible  by  otner  processors  tnrougn  a  Crossbar 
Swltcn . 

The  Crossbar  Swltcn  Is  a  system  tnat  enables  tne  designer  to 
increase  the  number  of  system  buses  to  tne  point  wnere  there 
Is  a  separate  patn  available  for  eacn  memory  unit.  Its 
obvious  advantage  is  to  eliminate  the  system  bus  contention 
wnen  operating  in  a  Multlprocessor/Multiprocess  environment. 
Since  many  real-time  applications  programs  reside  in  global 
memory,  tne  Bencnmarfc  test  were  conducted  In  tne  global 
memory  stored  program  environment.  Processing  power  of  a 
system  of  computers  sharing  a  common  systems  bus,  is 
measured  In  relative  efficiency  (see  Cnapter  IV.  3.).  Eacn 
processor  must  be  able  to  process  tne  program  steps  and  lata 
wltnout  Interfering  witn  eacn  otner  by  saturating  tne  system 
bus  with  request  for  instruction  and  data  fetches. 

Analysis  of  tne  INTEL  432/67(0  system  Benchmark 
performance  test  show  tnat  tne  relative  efficiency  of  tne 
system  is  still  approximately  90  percent  with  four 
processors  In  tne  system.  Tne  effectively  maximum  number  of 
processors  is  confirmed  at  six.  This  Is  In  snarp  contrast  to 
an  effectively  maximum  of  two  processors  for  tne  INTEL  8086 
operating  witp  a  MULTIBUS  systems  bus  fKODRESJ .  Again  It  is 
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emphasized  toat  tnese  performance  figures  are  cased  on  a 
common  memory  stored  program  system. 

Altnougn  tnis  tnesis  was  not  concerned  with  transparent 
multiprocessing'  the  advantages  of  a  system  that  supports 
this  concept  was  evident.  During  Bencnmaric  program 
executions,  a  processor  was  prevented  from  being  initialized 
due  to  a  loose  piece  of  plastic  in  tne  motherboard  card  edge 
connector.  Tne  system  continued  to  function  automatically 
sequencing  tne  extra  process  into  tne  dispatching  queue.  The 
actual  failure  was  only  discovered  wnen  attempting  to 
determine  a  sudden  increase  in  execution  times. 

Benchmark  programs  for  this  project  were  written  in  the 
Department  of  Defense  programming  language  Ada.  Previously 
generated  code  was  found  to  be  self-documenting,  easy  to 
modify,  and  interfacing  problems  were  non-existant .  Although 
Ada  has  been  cited  as  a  complex  language,  the  ease  with 
which  it  is  modified  combined  with  its  strong  typing 
characteristics,  and  readability  confirms  its  ability  to 
support  the  Software  Engineering  principles. 

While  tne  effectively  maximum  number  of  processors  for 
general  purpose  computing  in  the  INTEL  432/670  system  is 
comfirmed  at  six  processors,  incorporating  tne  iAPX  432  into 
a  Crossbar  Switch  system  could  produce  a  system  capable  of 
supporting  up  to  50  processors.  Its  direct  military 
application  to  tactical  systems  requiring  a  growth  potential 
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is  exciting  particularly  wnen  considering  tne  ability  of  tne 
i  APX  432  to  support  transparent  multiprocessing. 

Since  current  Navy  microcomputers  sucn  as  tne  AN/AYX-? 
cannot  be  expanded  beyond  four  processors  witnout  reauirine 
major  restructuring  of  tne  existing  software,  it  is 
recommended  that  a  follow  on  study  be  conducted  to  determine 
if  a  large  system  is  feasible  using  tne  1APX  432  in  a 
Crossbar  Swltcn  system. 
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APPENDIX  A 


iAPX  432  VS  CONVENTIONAL  M4INFRAMES 

Tuts  appendix  provides  a  comparison  of  tne  IAPX  432 
Arcftitecture  and  tne  Architecture  of  Conventional 
Mainframes . 


Feature  of  Archit. 


MEMORY  organization 

Organization,  size 


! Convent.  Mainfr  { 
Architecture 


Logical  to  physical 
address  translation 


Protected  memory 
unit 

data  manipulation 
Expression 
evaluation 

Primitive  data 
types 


Floating  point 
hardware 

Addressing  modes 


PROGRAMMING 
ENVIRONMENT  SUPPORT 
Operating  system 


Linear 

2**24-2**32  bytes 


Sinele-level  map 

Page-based  reloc 
and  virtual  memor 

Fixed-size  page 


General  reeister 


Characters , 
unsigned  integers 
integers,  reals 

Yes 

Some  modes  not 
availaole  for  ail 
operands 


No  multi-process 
support 

No  support  for 
dynamic  storage 
!  alloctatlon 


iAPX  432 
Archi tecture 


Structured  segmented 
2**24  segments 
2**16  byte 

displacement 
2**445  byte  virtual 
address  space 
Two-level  map 

Segment-based  reloc 
and  virtual  memory 

Individual  program 
module  or  data 
structure 

StacK  or  memory-to- 
memory 

Characters,  unsigned 
integers,  inteeers, 
reals,  temporary 
reals 
Yes 

Symmetrical:  all 
modes  availaole  for 
every  operand 


Multi-process 
mecnanisms  in 
ha  rdware 
Dynamic  storage 
allocation 
{mechanisms  in 
!  nardware 


iHign 


level  language 


(Programming 

'methodology 


Very  limited  mult{Software-transparent 
multi-  processor  'multi-processor 
operation  if  any  'operation 

I 

Assembly  language {Oriented  toward  nign 
oriented  (level  languages 

Instruction  set  ! 

I 

I 

No  support  at  all JObject-based 

! arcbi tecture 
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APPENDIX  B 


PIN  INSCRIPTION 

This  appendix  provides  tbe  pin  description  of  tne  1APX 
432  general  lata  processor. 

43201  Pin  Description. 

Processor  Packet  Bus  Group. 

ACD15'-ACD0  (Address/Control/Data  lines.  Inputs,  nign 

asserted ) . 

PRO  (Processor  Paccet  bus  Request, Input, nign  asserted). 

ICS  (Interconnect  Status,  Input,  nign  asserted). 

Intra-GDP  Bus  Group. 

0 I15--UI0  (Microinstruction  Bus  lines.  Outputs,  nign 
asserted). 

IS6 — -IS0  (Intercnlp  Status  lines.  Inputs,  nign 

asserted) . 

System  Group 

FATAL/(Fatal,  Output, low  asserted). 

ALARM/ (Alarm  signal , Input , low  asserted). 
INIT/(Inltlallzatlon(Input,low  asserted ) . 

CLR/(Clear, Input, low  asserted) 

Hardware  Error  Detection  Group 
Master  (Master, Input, nign  asserted). 

HERR/(Hardware  Error, Output , low  asserted). 

Clocic  Group 

CLKA,  CLKB  (ClocK  A,  ClocK  B,  Inputs). 

Testing  Input 

RDROM/(Read  RDM, Input, low  asserted) 

Power  and  Ground  Connections. 

FCC  (4  pins). 

GND  (5  pins) 

?BB  (Internally  Generated). 

N.C.  (No  Connection,  4  pins) 
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43202  Pin  Description 
Processor  Packet  Bus  Croup 

PRO  (Processor  Pacicet  request,  Tnree-state  Output,  fti*n 
asserted) . 

ICS  (Interconnect  Status,  Input,  nigh  asserted). 

Bout  (Enable  Buffers  for  Output,  Output, nign  asserted). 

Intra-GDP  Bus  Group. 

uI15-uI0  (Microinstruction  Bus  lines.  Inputs,  nig 
asserted) . 

IS6-IS0(Intercflip  Status  lines.  Outputs,  ni*n  asserted). 
System  Group 

PCLK/(Processor  Clock,  Input,  low  asserted). 

CLR/(Clear, Input, low  asserted). 

Hardware  Error  Detection  Group. 

Master  (Master,  Input,  nign  asserei;  25*  nomonal  puilup 
on-cnip) . 

HERR/(Hardware  Error,  Open  Drain  Output,  low  asserted). 
Clock  Group 

CLCA,  CLKB  (Clock  A,  Cloc*  B,  Inputs). 

Power  and  Ground  Connections. 

fee  (Power  Supply,  4  pins). 

GND  (Ground,  5  pins). 

N.C.  (No  Connection,  7  pins). 


APPENDIX  C 


SAMP LI  PROGRAM  ILgTINGr  WITH  SgBMlJ  FILEg 
This  appendix  contains  all  the  necessary  flies  to 
generate  Multiprocessor/Multiprocesses  environment. 


CHARSl. MSS 

—  CHARS1  package  specification 

—  Tnls  is  the  ADA  specification  package  for  the 

—  CFA  cnaracter  searcn  bencnmark. 

—  CHARS 1 


package  SCHAR  is 

suotype  sublnt  is  integer  ranee  1..25fc>; 
type  txtarray  is  arrayd ..256)  of  cnaracter; 


arrayl  ,array2  :  txtarray; 
procedure  SEARCH(srchien,arglen 

arrayl  , array? 

loc 


end  SCHAR; 


IN  sublnt; 

IN  txtarray; 
OUT  integer) 


f 


cHiagi^ais 

—  CHARSl  package  body 


—  Tne  following  package  contains  the  procedures  needed  to 

—  implement  the  CFA  character  searcn  benchmark.  Procedure 

—  SEARCH  performs  tne  actual  searcn  as  desired  by  tne  CFA. 

—  CHARSl 


pragma  environment  "ACS:TEXTIO.MLE","lNTIO.MSS", 

"SCHAR.MSE”); 

with  text.iOfintl o;  use  textile, intio , ascii ; 
package  body  SCHAR  is 

procedure  SSARCH(srcnlentargien  :  IN  sublnt; 

arraylfarray2  :  IN  txtarray* 

loc  :  OUT  Integer)  Is 


1«J  :  Integer; 
beein 
i  :»  1; 

J  :»  1? 
loc  :»  -1J 

vnile  1  <*  srcaien  loop 
if  arrayl(l)  *  array2ij)  tnen 
if  J+l  <«  arglen  tnen 
i  :*  i+U 
j  :*  j+i; 
else 

loc  :*  i ~J{ 
exit; 
end  if; 
else 

i  :*  i+i; 

J  :«  1  ,* 
end  if; 
end  loop; 
end  SEARCH* 
end  SCHAR; 


PR1MAIN.MSS 

package  USER  J>R0CESS_1  is 
procedure  MAIN? 
end  USER  PROCESS  i; 


PR2MAIN .MSS 


package  USER_PR0CESS_2  Is 
procedure  MAIN; 
end  USER  PROCESS  2; 


PR3MAIN «MgS 


package  USERJ>R0CESS_3  is 
procedure  MAIN; 
end  USER  PROCESS  3; 


package  USER_PR0CESS_4  is 
procedure  MAIN; 
end  USER  PROCESS  4; 
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PR1MAIN.M|S 

— CHARS  1  driver  routine 


pragma  environment  "ACS: TEXT  10. MLE"  ."INTIO.MSE'V’SCHAR.MSS"  * 

"PR1MAIN .MSB" ) » 

with  text  io ( lntio, schar;  use  text_iotlntio, schar, ascii ; 


~  Timing  also  includes  time  for  procedure 

—  invocation 

—  3  May  1983 

package  body  0SER_PROCESS_1  is 
procedure  MAIN  Is 

1 ,loc,srcn_lengtn,srcn_arg,timer_ioop  :  Integer; 
begin 


—  Initialisation 


arrayi  •*  (M,o«n«d,a,y,ff  ,  J  ,  u  ,  n  , 
e  t  t  ,  t  ,  n  ,  •  t  ,  i  ,  y  ,  r  ,  o  , 

otners  *>  '  '); 

array2  :*  ( 'd' , 'a', 'y' .otners  «>  '  ')» 
srcn  length  :»  22; 
srcn“arg  :*  3; 
timer_looj>  :=  100000; 

put~20(  Start  of  Search.  ..l"); 

putTBEL ) ; 

put (BEL ); 

put (BEL ); 

put (BEL); 

put  (BEL ) ; 

for  1  In  1..  timer  loop  loop 

SEARCH ( srcn_lengtn7srcn_arg,arrayl .array 2, loci ; 
end  loop; 

put  20(  end  the  search . l" ) ; 

putTBEL )» 
put (BEL); 
put (BEL )» 
put (BEL ) * 
put  (BEL); 
end  MAIN; 

end  USER  PROCESS  i; 
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-C  HA  RSI  driver  routine 


praema  environment ( "ACS :T5XTI0.MLE" , " INTI 0. MSB” ."SCHAR.MSE 

"PR2MAIN.MSE"); 

vitn  text_io,lntio, schar;  use  text_io,intio,scnar, ascii; 


—  Tlmine  also  Includes  time  for  procedure 

—  invocation. 

—  3  may  1983 

packaee  body  0SERJPROCESS  J2  is 
procedure  MAIN  is 

i  ,loc  ,srcb_lengtn ,srcn_arg , time r_lo op: integer; 
begin 


—  initialization 


arrayl  :*  ( 'm\  'o'/n'  ,'d  'a  \  'yV.  '  ','J','u 

/  *  0  n  0  »  »  0  0  0  0*0  * n  *  * n f  0c 

e»»*t#n*ft  •  l  •  9  •  >  •  5 

^  _  _  .  _  v 


'n 


array2  :*  ( 'd' , 'a' , *y' , otbers  *> 


otners  *> 


srcn  lenetn  :»  22; 
srcn^arg  :»  3; 
timer_loog  :*  100000; 

put  20 (  Start  of  Searcn. . .2" ) ; 

putlBEL); 

put  (B51); 

put (BEL) ; 

put (BEL ); 

pu  t ( BEL ) ; 

for  i  in  1..  timer_loop  loop 

SEARCH( srcn_lengt n7srcn_arg,ar ray l , array-2, loc) ; 
end  loop; 

put  20 (  end  tne  searcn . 2”); 

putlBEL); 
put (BEL); 
put (BEL); 
pu  t ( BEL ) ; 
put (BEL); 
end  main; 

*nd  USER  PROCESS  21 


PR3MAIN .MBS 


— CHARS  1  driver  routine 


pragma  environment  "ACSjTEXTIO.MLE"  ,’,lNTIO.MSE”,"SCHAR.MSE' 

"PR3MAIN .MSE" ) ; 

tfitQ  text_io .intio, scnar;  use  text_io, intio, scnar,  ascii; 


—  Timing  also  includes  time  for  procedure 

—  invocation. 

3  May  1983 

pacfcaee  body  USER_PR0CESS_3  is 
procedure  MAIN  is 

i ,loc,srch_length,srch_arg,timer_loop  :  integer* 
begin 


—  initialization 


„  .  /  z^./  *  0  /  _  ^  /.  #  0  /  /  _  /  0  0  0  0  0  f  0  * «.  0  0^0 

d  rrsyl  • ~  (MtOf&ydfdfyt  f  ^  y  J  ^  u  i  n 
0  0  0„0  0  0  0^  0  0  0  0  0  0*0  0Q0  0n0  0^0 
e  ,  7  ,  t  ,  h  ,  ,  ,  .1,9,  r.b, 

others  =>  ) 

array2  :=  ( , 'a', #y' .others  *>  '  '); 
srcn_leneth  :=  22; 
srcn_arg  :*  3; 
tlmer_loop  100000; 

put  20(”  Start  of  Search ..  .3"  ) ; 

pucCBEL )* 

put (BEL  ); 

put(BEL); 

put  (BEL  )» 

put (BEL); 

for  i  in  1..  timer  loop  loop 

SEARCH( srcn_lengtfl7srcn_arg.arrayl.array2.loc) ; 
end  loop; 

put  20( ‘end  the  search . 3“); 

putlBEL ); 
put(BSL), 
put (BEL ) ; 
put  (BEL  )* 
put (BEL); 
end  MAIN; 

end  OSER  PROCESS  3; 
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PH4MAINaMBS 

— CHARS1  driver  routine 


praema  environment( "ACS: TEXT 10. MLS" • " I NT 10. MSB" » "s CHAR. MSB" 

"PR4MAIN.MSB"); 


witn  text_io .intio, scnar;  use  text_io, intio.scnar, ascii ; 


Timing  also  includes  tine  for  procedure 
invoca  tion. 

3  May  1983 


package  body  OSER _PR0CESS_4  is 
procedure  MAIN  is 

i ,loc,srcn-lengtn,srcn_arg ,timer_loop  :  integer; 
forever  s  boolean  :*true; 
answer  :  character; 

begin 


while  forever  loop 
—  initialization 


'  '  '*r'  0  0  0  0  0j  0  0  0  0  0 

Arr^yl  •*  lMfo#ntd#atyfff  9jvdfn 

0  0  09*0  0^0  0^0  0  *  0  0  0*0  0  r%  0  0  n  '  0'c0 


array2  :»  ( 'd'f 'a', 'y' .others  *> 


1'.  ,'6‘  , 

others  =>  '  ') 

); 


srch_lenwtn 

srcn”arg 

timer_loog 


22; 

3  ? 

100000; 

put_20( "  Start  of  Searcn . . .4"  ) ; 
putlBBL); 
put (BEL); 
put (BEL ). 
put (BEL); 
put (BEL ); 

for  i  in  l..  titner_loop  loop 

SEAHCH( srch_lesgth7srch_arg,arrayl,array2,ioc) ; 
end  loojj; 

put  20 (  end  the  search . 4”); 

putTBEL) ; 


put (BEL); 
put (BEL ) ; 
put (BEL ); 
put(BEL); 
forever  :* 
end  loop; 
end  main; 

end  (JSER  PROCESS  4; 


false; 
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DFPSERP! .MBS 

Pragma  environment "ACS : BPM.MLE" , "ACS :?1USRP.MLI" , 

PR1MAIN  .MSB  ,  PR2MAIN .MSB  ,  PR3MAIN.MSE" ,  PR4I*AIN  .HS  E”  )  * 
vl tli  Process_De?lnl tions ,  iMAX_Def initions, 

Basic  Process  management; 

with  Oser_Process  JL ,0ser_Pro cess J2 .Use r_Frocess_3, 

User_Process_4» 

package  body  Dser_Processes  is 

—  Function: 

—  This  module  instantiates  tne  user  processes  and 

—  provides  an  initialize  procedure  which  completes  the 
--  initialization  of  each  user  process. 

—  For  each  user  process,  there  is  an  instance  of 

—  iMAX_Definitlons.procelure_val  wnicft  contains  the 

—  process'  initial  procedure.  To  minimize  tne  size  of 

—  this  package,  tne  Initial  procedure  here  simply  calls 

—  tne  actual  initial  procedure  wnicn  is  found  ir. 

—  another  module.  For  each  process,  tnere  is  also  an 

—  Instantiation  of  Process_Pef ini tions .Process_Instance 

—  whlcn  specifies  the  process  id,  tne  proeedure_val 

—  Just  mentioned,  and  tne  process'  stactc  SRO  and  object 

—  table  sizes. 

Finally,  tne  initialize  procedure  provided  by  tnls 

—  module  simply  calls  the 

—  Complete_process_lnltialization  procedure 

—  In  eacn  instantiation  of 

—  Process_Defini tions .Process _Ins tan ce. 

procedure  prlmain; 
procedure  pr2main; 
procedure  pr3main; 
procedure  pr4malni 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  ~ 


package  UPROCl  is  new  ProcessJ)er  ini  tions  .Process_Instaace 
(Process  Startup  a>  prlmalnT 
SR0_size  *>  4000); 

—  servlce_perlod  *> 

baslc_process_management . inf ini  temper! od_count ) ; 
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—  SPECIFICATIONS  FOR  USSR  PROCESS  2 


package  UPR0C2  Is  new  Process_Definitions.Process_Instance 
(Process  Startup  =>  pr2main, 

SR0_sl2e  «>  4000); 

—  service_period  => 

basic_jjrocess  jnanagement  .lnflnite_period_count ) 


—  SPECIFICATIONS  FOR  USSR  PROCESS  3  - 


package  UPR0C3  is  new  Process  J)efinitions.Process_Instance 
(Process_Startup  =>  prSnainT 
SRO^size  ®>  4000); 

—  service^perlod  *> 

Basic_process  jnanagement. infini te_period_count ) 


—  SPECIFICATIONS  FOR  USER  PROCESS  4 


package  UPR0C4  is  new  Process_Def initions .Process  Instance 
(Process  Startup  »>  pr4main7 
SRO_$lze  *>  4000); 

— ■  serf ice  jperlod  *> 

Basic  Process  Management . Inf inite  Period  counts 


—  BODIES  FOR  USER  PROCESS  1  - 


procedure  prlmain  is 
Begin 

Use r_Process_l. MAIN; 
end  prlmain; 


—  BODIES  FOR  USER  PROCESS  2 


procedure  pr2maln  is 
Begin 

User_Process_2,main; 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  - 


procedure  pr3main  Is 
be*?  In 

User_Process_3.main; 
end  pr3main» 


~  BODIES  FOR  OSER  PROCESS  4  — 


procedure  pr4main  Is 
begin 

Use r_Process_4. main? 
end  pr4malni 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 
is 

bearin 

UPROCl.Complete_process_lnitiaiization; 

—  UPROC2.Complete~process_ini tiali 2a t ion; 

—  UPROC3.Comple  te_process“inltialization; 

—  UPROC4.Complete“pro cess "ini tiali zatlon; 
end  Initialize; 

end  User  Processes; 


DFPSSRP2.MBS 

Pragma  environment  "ACS  :  BPM.MiE" ,"aCS  :  FlUSRP.MLI*’  , 

"PR1M4IN.MSE",’PR2MAIN.MSEm,"PR3MAIN.MSE","pR4m.AIN.*-SE"  }  5 
vita  ProcessJ)eflni  tions.  itfAX_Def initions , 

Basic  Process  management; 

with  &ser_Process_l  ,0ser  J?rocess_2,User_Frocess_S, 

User_Process_4; 

package  body  User_Processes  is 

—  Function: 

—  This  module  instantiates  tne  user  processes  and 

—  provides  an  initialize  procedure  wnicn  completes  tne 

—  initialization  of  each  user  process. 

—  For  each  user  process,  taere  is  an  instance  or 

—  iMAX_Defiaitlons.procelure_val  which  contains  the 

—  process'  initial  procedure.  To  minimize  tne  si2e  or 

—  this  pactcage,  tae  initial  procedure  here  simply  calls 

—  tae  actual  initial  procedure  which  is  found  in 

—  another  module.  For  each  process,  tners  is  also  an 

—  instantiation  of  Process_Definitions.Process_Instance 

—  wnlcn  specifies  tne  process  id,  tne  procedure_va i 

—  Just  mentioned,  and  tne  process'  stacit  SRO  and  object 

—  table  sizes. 


Finally,  tne  initialize  procedure  provided  by  this 
module  simply  calls  tne 
Complete_process_inltialization  procedure  in  each 
instantiation  of~Process  Deflnitions.Process  Instance 


procedure  prlmaln; 
procedure  pr2maini 
procedure  prSmain; 
procedure  pMmaini 


—  SPECIFICATIONS  FOR  USER  PROCESS  1 


package  UPR0C1  is  new  Process_Def ini tions.Process_Instance 
(Process  Startup  =>  prlmainT 
SRO_slze  =>  4000); 

—  service_period  *> 

basic,j>roce5S_management .  inf  ini  te_period_count ) ; 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2  — 

package  UPROC2  is  new  Process_Definitions.Process_Instance 
(Process  Startup  =>  pr2maln, 

SRO_size  *>  4000); 

—  service_perlod  *> 

ba  si  c_pro  cess  management  .lnfinlte_period_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


package  UPR0C3  is  new  Process_Definitions.Process_Instance 
(Process  Startup  =>  pr3main7 
SRO_sl2e  =>  4000)* 

—  serfice_period  => 

basic_process_mana8eiTiettt .  infinite_perloc_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacKaee  UPR0C4  is  new  Process_Defini tions .Process_Ins tance 
(Process  Startup  =>  pr4maln7 
SRO_size  *>  4000); 

—  servlce^perlod  *> 

Baslc_Processmanagernent .  Inf  ini  te_Perlod_count ) 


BODIES  FOR  USER  PROCESS  1 


procedure  prlmain  is 
begin 

User_Process_l.MAIN 
end  prlmain; 


BODIES  FOR  USER  PROCESS  2 


procedure  pr2main  is 
begin 

Use r  JProcess_2. main 
end  pr2main; 


-  BODIES  FOR  USER  PROCESS  3  — 


procedure  prSmain  Is 
be*ln 

User_Process_3.main; 
end  pr3maln; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  is 
begin 

User  Process  4. main; 
end  primain; 


~  PROCEDURE  TO  INITIALIZE  kll  USER  PROCESSES 

procedure  Initialize 
is 

begin 

UPR0C1. Couple te_process_ini t ialization* 
UPROC2.Complete~process~initialization; 

—  UPR0C3. Comple te”proce ss~i nl tiali za  tion* 

~  UPROC4.Complete_process_lnl tiali zation ; 
end  Initialize; 

end  User  Processes; 
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DFPSERP3.M1S 

Praema  environment( ”ACS:BPM.MLE" ,"aCS :7lUSRP.MLl” , 

"PR1MAIN .MSB  f’PR2MAIN.MSE”,"PR3MAIN.MSB","PR4WAIN.KSE”) J 
with  Process_Def ini tions,  lMAX_Def ini tions, 

Basic  Process  management; 

with  User_Process_l ,User_Process_2 ,User_Process_5 , 

User_Prof'ess_4* 

package  body  Oser_Processes  Is 

—  Function: 

--  This  module  instantiates  the  user  processes  and 

—  provides  an  initialize  procedure  which  completes  tne 

~  initialization  of  each  user  process. 

—  For  eacn  user  process,  mere  is  an  instance  of 

—  i^AX_Deflnitions.procedure_val  which  contains  tne 

—  process'  initial  procedure?  To  minimize  the  size  of 

—  this  package,  the  initial  procedure  here  simply  calls 

—  the  actual  initial  procedure  wnicn  is  found  in 

another  module.  For  each  process,  there  is  also  an 

—  instantiation  of  Process_Definitions.Process_Instance 
wnicn  specifies  tne  process  id,  the  procedure_va i 

—  Just  mentioned,  and  the  process'  stack  SRO  and  object 
table  sizes. 


Finally,  the  initialize  procedure  provided  by  this 
module  simply  calls  tne 
Complete_process_lnltlailzation  procedure  ir.  each 
instantiation  of  Process  Definitions . Process  Instance 


procedure  prlmainj 
procedure  pr2main» 
procedure  pr3main» 
procedure  pr4main» 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


package  UPR0C1  is  new  Process_Def ini tions .Process_Instance 
(Process_Startup  =>  prlmain? 

SR0_size  =>  4000); 

—  service_periol  *> 

basic_pro  cess  management .  infi  ni  te_period_count ) » 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2  — 


package  UPR0C2  is  new  Process_Def tuitions .Process_Instance 
(Process  Startup  *>  pr2main, 

SR0_si  ze  *>  4020); 

—  service.jperiod  *> 

ba  si  c_pro  cess  ..management . infinite_period_count ) 5 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


package  UPR0C3  is  new  Process_Deflnitions.Process_Instance 
(Process  Startup  »>  pr3maln7 
SRO.size  =>  4000); 

—  service_period  *> 

basic_process_mana*ement. infini te_period_count )» 


SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  UPROC4  is  new  Process_Definitions.Process_Instance 
(Process  Startup  =>  pr4maia7 
SRO_slze  *>  4000); 

—  service_peri od  => 

Basic„Process_Mar.agement.  Inf  ini  te_?eriod_count) ; 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  primain  is 
begin 

Use r_Process_i. MAIN; 
end  primain; 


BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2main  is 
begin 

User_Process_2.main; 
end  pr2main» 


1X1 


1 

i 


—  BODIES  FOR  USER  PROCESS  3  — 


procedure  pr3maln  is 
be*ln 

User_.Process_3.main; 
end  pr3main; 


BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  is 
begin 

User_Process_4.maln; 
end  pr4maln; 


PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 


procedure  Initialize 
is 

begin 

UPROCl.Compiete_process_lnitiaiization; 
UPR0C2.Complete_process_lnl tlaliza tion; 
UPROC3.Comple te”process  initialization; 
—  UPROC4.CompIete”processIlni tiaii zaclon; 
end  Initialize; 

end  User  Processes; 


i 


DFPSERPii^BS 

Pragma  environment  "ACS  :£PM.*LE"  ,"ACS  :?1USRP.MLI"  , 

PR1MAIN .MSB" ,  PR2MAIN .MSB  ,'*PR3MAIN .MSB" ,  PR4MAIN .MSB” ) ; 
vita  Process_Defini tions,  iMAX_Def ini tions, 

Basic  Process ^management > 

wit ft  User_Process_l ,User_Process_2 ,User_Frocess_5, 

User_Process_4  f 

package  body  Oser_Processes  is 

—  Function: 

Tnls  module  instantiates  tne  user  processes  and 

—  provides  an  initialize  procedure  wnicn  completes  tne 
initialization  of  eacn  user  process. 

—  For  eacn  user  process,  mere  is  an  instance  of 

—  iMAX_Definitions.procedure_val  wnicn  contains  tne 
process'  initial  procedure.  To  minimize  tne  size  of 
tnis  package,  tne  initial  procedure  nere  simply  calls 

—  tne  actual  initial  procedure  wnicn  is  found  in 

—  another  module.  For  eacn  process,  mere  is  also  an 

—  instantiation  of  Process_Def ini tions. Process_Instance 

—  wnicn  specifies  tne  process  id,  tne  proceiure_val 
Just  mentioned,  and  tne  process'  staca  SRO  and  object 

—  table  sizes. 

—  Finally,  the  initialize  procedure  provided  oy  tnis 

module  simply  calls  tne 

—  Complete_process_lni tiali zatlon  procedure  in  eacn 
instantiation  of~Process  Def ini tions .Process  Instance 


procedure  primaln; 
procedure  pr2main; 
procedure  pr3maln» 
procedure  pr4maln» 


—  SPECIFICATIONS  FOR  tfSER  PROCESS  1  — 


package  UPR0C1  is  new  Process_Def initions.Process_Instance 
(Process  Startup  *>  primaln, 

SRO_slze  *>  4000); 

—  service_perlod  *> 

Dasic_process_managemen t . inf ini te_period_count ) » 


113 


—^SPECIFICATIONS  FOR  USER  PROCESS  2  — 


pacKace  UPR0C2  is  new  Process_Definitions.Process_Instance 
(Process  Startup  *>  pr2maln, 

SRO.si ze  «>  4000); 

—  service.perlod  *> 

oa  slc.process .management . lnflnl te.perlod.count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  3 


package  0 PR0C3  is  new  Process.Definl  tions  .Process_Instance 
(Process  Startup  *>  pr3malnt 
SRO.slze  *>  4000); 

—  servlce.perlod  *> 

basic  jprocess .management . Inf Ini te.perlod.count )  * 
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SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacKare  UPR0C4  Is  new  Process_Definltlons .Process_Instauce 
(Process  Startup  ■>  pr4main, 

SRO_size  *>  4000); 

—  serrice_period  ■> 

Basic_Process_Management . Inf inite_Perioa_count ) 


-  BODIES  FOR  USER  PROCESS  1  - 


procedure  prlmaln  is 
beein 

User_Process_l.MAIN; 
end  prlmaln; 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2main  is 
begin 

User_.Process_2.main; 
end  primain; 


BODIES  FOR  USER  PROCESS  3 


procedure  pr3maln  is 
beeln 

User_Process_3.main ; 
end  primain; 


—  BODIES  FOR  USER  PROCESS  4  -- 


procedure  pr4main  is 
begin 

Use r_Process_4. main; 
end  primain; 
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-L -  -  - 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  ~ 


procedure  Initialize 
is 

begin 

0PROCl.Complete_process_init la liza lion; 
UPROC2.Comple te”process_ini tiali2ation; 
0PS0C3, Complete  process  Ini tializa tion; 
UPROC4.Complete“processIinitlali2atlon» 
end  Initialize; 

end  User  Processes; 
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DFLINK1.LKD 

;  instruction  test  program 

link;  ACS sminmax.eod 

ACS :teztio.mlo 

intio.mso 

scnar.mso 

sehar .mbo 

prlmain.mso 

pr2mai n.mso 

pr3main.mso 

pr4main.mso 

prlmain .mbo 

pr2main.moo 

prSmain.mbo 

pr4main.mbo 

dfpserpl .mbo 

psors .mbo 

free(30  in  directory) 
output  dfcharl.eod 
objectmap 


DFLINF2.LO 


;  instruction  test  program 

link  ACS rmlnmax.eod 

ACS :textio.mlo 

intio.mso 

schar  .mso 

scnar .mbo 

prlmain.mso 

pr2main.mso 

pr3main  .mso 

pr4main.mso 

prlmaln .mbo 

pr2maln.mbo 

pr3maln.mbo 

pr4main.mbo 

dfpserp2.mbo 

psors .mbc 


free{30  in  directory) 
output  dfcnar2.eod 
objectmap 


gZIIJSUSillfi 


;  instruction  test  program 

link  ACS :mlnmax.eod 

ACS :teztlo  .mlo 

lntlo.mso 

schar .mso 

scnar.mbo 

prlmaln.mso 

pr2maln.mso 

prSmain.mso 

pr4main.mso 

prlmain.mbo 

pr2main.mbo 

pr3maln.moo 

pr4maln.mfco 

dfpserp3.mbo 

psors .mbo 

free(30  in  directory) 
output  dfcflar3.eod 
objectmap 


;  instruction  test  program 

linK  ACS jminmax.eod 

ACS  stextlo .mlo 

lntlo.mso 

scnar .mso 

scnar.mbo 

prlmaln.mso 

pr2main.mso 

pr3main.mso 

pr4maln.rrso 

prlmain.mbo 

pr2maln.mbo 

prSmaln.mbo 

pr4 main. mbo 

If pserp4.mbo 

psors  .mbo 

rree(30  In  directory) 
output  dfcnar4.eod 
objectmap 
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iNFPSEHPl.yBS 

Pragma  environment "ACS  sBPM.MLE” , 'ACS  :  VlUSRP.MLl" , 

"PR1MAIN  .MSE", "PR2MAI  N  .MSE"  ,*'PR3MAlN  .MSE”  ,  "PR4MAIN  .t*S  E"  ) ; 
vitn  Process_Deflnitions ,  iMAX_Def lnitions, 

Basic  Process  management* 

vitn  User_Process_l ,User_Process_2 ,User_Process_3, 

User_Proress_4 ; 

package  body  User_Processes  is 

—  Function: 

—  Tnis  module  instantiates  tne  user  processes  and 
provides  an  Initialize  procedure  vnicn  completes  tne 
initialization  of  eacn  user  urocess. 


For  eacn  user 
iMAX_Def initions 
process'  initial 
tnis  package,  tn 
tne  actual  ini 
anotner  module, 
instantiation  of 
vnicn  specifies 
Just  mentioned, 
table  sizes. 


process,  tnere  is  an  instance  of 
,procelure_val  vnicn  contains  tne 
procedure.  To  minimize  tne  size  of 
e  initial  procedure  nere  simply  calls 
tial  procedure  vnicn  is  found  in 
For  eacn  process,  tnere  is  also  an 
Process _Def in  it ions .Pro  cess _I ns tance 
tne  process  id,  tne  proceaure_vai 
and  tne  process'  stack  SRO  ana  object 


—  Finally,  tne  initialize  procedure  provided  by  this 

—  module  simply  calls  tne 

—  Complete_process_initialization  procedure  in  eacn 

—  instantiation  of  Process_Def lnitions.?rocess_Instance 

procedure  prlmain; 
procedure  pr2main; 
procedure  pr3maini 
procedure  pr4maini 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


package  UPROC1  is  nev  Process_Definitions.Process_Instan~e 
(Process_Startup  =>  prlmain, 

SR0_slze  =>  4000, 
service_period  => 

oasic_process_management.lnfinl te_period_count ) * 
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SPECIFICATIONS  FOR  USER  PROCESS  2  — 


package  UPR0C2  Is  new  Process_Defini tlons .Process_Ins tance 
(Process  Startup  =>  pr2main, 

SR0_size  =>  4000, 
service_period  => 

basic_process_management  .in?inite_period_count ) » 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


packa*e  UPR0C3  is  new  Process_Defini tlons. Process_Instance 
(Process_Startup  =>  pr3nain7 
SRO_slze  *>  4000, 
service_period  *> 

basicjsrocess management  .inf ini  te_perloa_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  UPR0C4  is  new  Process_Definitions.Process_Instance 
(Process  Startup  «>  pr4main, 

SRO_sl ze  *>  4000, 
service^period  *> 

Basic_Process_P!anagement .  Inf  ini  te_Period_count ) ; 


BODIES  FOR  USER  PROCESS  1 


procedure  prlmaln  is 
begin 

User_Process_l.MAIN ; 
end  prlmaln; 


—  BODIES  FOR  USER  PROCESS  2 


procedure  pr2maln  is 
beein 

UserJProcess_2.main» 
end  pr2main» 


BODIES  FOR  USER  PROCESS  3  — 


procedure  pr3main  is 
begin 

Use r_Process_3. main; 
end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4maln  is 
beei  n 

Use r_Process_4. main* 
end  primain; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES 


procedure  Initialize 
is 

begin 

UPROC1 .Comple te_process_ini tiali zation; 

—  UPR0C2. Couple te "pro cess”ini tialization* 

—  UPROC3.Complete_process_ini tiali zation; 

—  UPROC4. Comple te_process~i ni tiali za  tion; 
end  Initialize; 

end  User  Processes; 
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INyPS.SBg2j.MES 


Pragma  environment  "ACS: BPM.^IE"  ,’*ACS  :V1USRP.MLI” , 

PR1MAIN .MS  E " , ’ PR2MAI N .MS  E" » "PR3MA IN . MSE" , "PR4MAIN .MSS" ) ; 
with  Process _Defini tions ,  iMAX^Def inltlons , 

Basic  Process  mar.agemert » 

wltn  User_Process_l  .Use r_Pro cess  _2  ,TJser_Process_3 , 

User_Process_4» 

pacica«e  body  User_Processes  is 

—  Function: 

—  Tnls  module  instantiates  tne  user  processes  and 

—  provides  an  Initialize  procedure  which  completes  tne 

—  Initialization  of  eacn  user  process. 

—  For  eacn  user  process,  tnere  is  an  instance  of 

—  iMAX_Deflnitions.procelure_val  which  contains  tne 
process'  initial  procedure.  To  minimize  tne  size  of 

—  this  package,  the  initial  procedure  nere  simply  calls 

—  tfie  actual  initial  procedure  whicn  is  found  in 
anotner  module.  For  eacn  process,  tnere  is  also  an 

—  instantiation  of  Process_Def lnltlons .Process_Instanre 

—  vnicn  specifies  tne  process  id,  tne  proceaure_va > 

—  just  mentioned,  and  the  process'  stacJc  SRO  and  object 

—  table  sizes. 

Finally,  tne  initialize  procedure  provided  Dy  this 

—  module  simply  calls  the 

—  Complete_process_inltialization  procedure  in  each 

—  instantiation  of  Process_Deflnltions.Process_Instance 

procedure  prlmainf 
procedure  pr2main; 
procedure  pr3main; 
procedure  pr4maln; 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


pac«a*e  UPROC1  is  new  Process_Def inltions.Process_Instance 
(Process  Startup  »>  prlmaln, 

SRO_size  *>  4BtfB, 
servlce_perlod  ■> 

basic_process_management . inf inite_perioc_count )  * 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2  ~ 


paclra*e  UPR0C2  Is  new  Process_Definitions.Process_Ir.stance 
(Process  Startup  =>  pr2main, 

SRO_size  *>  4000, 
service_perlod  => 

basic_process  jnanagement . inf ini te_period_count ) 


SPECIFICATIONS  FOR  USER  PROCESS  3  — 


pacra*e  UPR0C3  is  new  Process_De?initions.Process_Instance 
( Process_Sta rtup  =>  pr3main7 
SRO_size  =>  4000, 
service_period  => 

basic  ja  recess  ^management  . infinlte_perlod_count ) 


~  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacicaare  UPR0C4  is  new  Process_Eefinitlons.Process_Instance 
(Process_Startup  =>  pr4main7 
SRO_size  =>  4000, 
servlce_periol  => 

Basic_Process_Management .  Inf  ini  te_Period_count ) 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmaln  is 
begin 

Use r_Process_I. MAIN? 
end  prlmainj 


—  BODIES  FOR  USER  PROCESS  2  -- 


procedure  prPmain  is 
begin 

User_Process_2.main» 
end  pr2maini 
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—  BODIES  FOR  USER  PROCESS  3  — 


procedure  pr3roain  Is 
be^in 

Use r_Process_3. main* 
end  pr3main* 


BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  Is 
begin 

Use r_Process_4. main* 
end  pr4main* 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 


procedure  Initialize 
is 

t>esin 

UPROCl.Co7ipiete_process_initialization; 
0PR0C2.Complete~process_ini tiaiiza tion» 

—  UPR0C3. Couple  te^process^ini tlaiization; 

—  UPROC4. Complete^pro cess  ini tializa ti on* 
end  Initialize* 

end  User  Processes* 


INFPS  BRP3.MBS 

Pragma  environment  "ACS  :BPM. MIE”  ,  "ACS  :V1USRP.MLI" , 

PR1MAIN .MS  E* , ’ PR2MAI N .MSE" , "PR3MA IN .MSB” , "PR4MAIN .MS  E"  ) ; 
with  Process_Definitions ,  lMAX_Def initions, 

Basic  Process  management; 

with  Hser_Process_l , Use r_Process_a, tJser_Fro cess _3, 

User_Precess_4; 

pacica<re  oody  User_Processes  Is 

—  Function: 

—  This  module  instantiates  me  user  processes  and 

—  provides  an  initialize  procedure  which  completes  tne 

—  initialization  of  eacn  user  process. 

For  eacn  user  process,  tnere  is  an  instance  of 
iMAX_Definitions.proceiure_vai  which  contains  the 

—  process'  initial  procedure.  To  minimize  tne  size  or 

—  this  package,  tne  initial  procedure  nere  simply  cans 

—  the  actual  initial  procedure  which  is  found  in 

—  anotner  module.  For  eacn  process,  tnere  is  also  an 

—  instantiation  of  Process^Def initions.Prccess_Instance 

—  wnicn  specifies  the  process  id,  the  procedure_val 

—  Just  mentioned,  and  the  process'  staci  SRO  and  ocject 
taoie  sizes. 

—  Finally,  the  Initialize  procedure  provided  oy  this 

—  module  simply  calls  tne 

—  Complete_process_lnltlalizatlon  procedure  in  each 

—  instantiation  of  ProcessJJef initions.Process_Instance 

procedure  prlmain; 
procedure  prlmain; 
procedure  pr3main; 
procedure  pr4maln; 


—  SPECIFICATIONS  FOR  CJSER  PROCESS  1  — 


pacita*e  UPPOC1  is  new  Process_Definitions.Process_Instance 
(Process_S tar  tup  =>  prlmain, 

SR0_size  4000, 
service_period  *> 

oaslc_process_management. inf ini te_period_count ) ; 
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-  SPECIFICATIONS  FOR  USER  PROCESS  2 


pacicage  UPR0C2  is  new  Process_Definitions.Process_Instance 
(Process  Startup  *>  pr2main, 

SRO_size  *>  4000, 
service_period  => 

oasicjarocess  jnana*ement . inf ini te_period_count  ) 


—  SPECIFICATIONS 


USER  PROCESS  3  — 


package  UPR0C3  is  new  Process_Def ini tions .Process_Instance 
(Process  Startup  =>  pr3inainT 
SRO^slze  =>  4000, 
service_period  *> 

oasicjprocess  jranatfement.infini te_period_count ) 


—  SPECIFICATIONS  FOR  USER  PROCESS  4 


pactage  UPR0C4  is  new  Proces$_Definitions.Process_Instance 
(Process  startup  *>  pr4main7 
SRO^slze  =>  4000, 
servlce_period  => 

Basle  Process  Management . Infinite  Period  count) 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmam  is 
oegin 

User_Process_l.MAIN; 
end  prlmam; 


—  BODIES  FOR  USER  PROCESS  2 


procedure  pr2main  is 
t>e»i  n 

User_Process._2.main; 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procedure  pr3maln  is 
t>e*in 

Use r_Process_3. main; 
end  pr3main« 

—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4maln  is 
be<?ln 

User  Process_4.maln; 
end  pr4maln# 


—  PROCEDURE  TO  INITIALIZE  ALL  USSR  PROCESSES 

procedure  Initialize 
Is 

oeein 

UPROCl.Compiete_process_lnltlallzation; 
UPR0C2. Complete  process_lnltiali ration; 
UPR0C3.Complete_process_inltiallza tlon; 

—  UPROC4.Compiete_processIlnit lali zation » 
end  Initialize; 

end  User  Processes; 
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INFPSBRP4.MBS 

Pragma  environment("ACS:BPM.MLE","ACS :  V1USRP .MLl" , 

"PBmiN.ME  ,  PR2MAI N .MSE" ,  PR3MAIN.  MSB"  , *  PR4!*AlN  . MS E"  ) » 
with  Process_Def lnl tions ,  lv!AX_Def  initions, 

Basic  Process  management* 

with  User_Process_l ,Oser_Process_2 ,User_Frocess_3, 

Usir_Process_4f 

pacfcasre  body  0 ser_Processes  is 

—  Function: 

This  module  instantiates  tne  user  processes  and 

—  provides  an  Initialize  procedure  which  completes  tne 
initialization  of  eacn  user  process. 


For  eacft  user 
lMAX_Defini tions. 
process  'ini tial 
tnis  padca*e,  tne 
tne  actual  lnlt 
another  module. 
Instantiation  of 
whlcn  specifies 
Just  mentioned,  a 
table  sizes. 


process,  there  Is  an  instance  of 
procedure_vai  which  contains  tne 
procedure.  To  minimize  tne  size  of 
Initial  procedure  nere  simply  cans 
ial  procedure  which  is  found  in 
For  each  process,  there  is  also  an 
Process_Def ini tions .Process_Instance 
the  process  id,  the  proceaure_vai 
nd  the  process'  stacfc  SRO  and  object 


Finally,  the  initialize  procedure  provided  Dy  tnis 

—  module  simply  calls  tne 

—  Complete_process_ini tialization  procedure  in  each 

—  instantiation  of~Process  J)efinitions.Process_Instance 

procedure  prlmain; 
procedure  pr2maln; 
procedure  pr3main* 
procedure  pr4main; 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  ~ 


pacKa*e  UPROC1  Is  new  Process_Definitions.Process_Instance 
(Process  Startup  *>  prlmain, 

SR0_size  =>  400tf, 
servlce_perlod  *> 

ba si c ^process management .  inf  inite_period_count ) » 


—  SPECIFICATIONS  FOR  USER  PROCESS  2  — 


package  UPR0C2  is  new  Proeess_Definitlons.Process_Instance 
(Process  Startup  *>  pr2main, 

SRO_slze  *>  40(30, 
service_period  *> 

basic_process_management. lnfinite_period_count ) 


SPECIFICATIONS  FOR  USER  PROCESS  3  — 


package  UPROC3  is  new  Process  Defini tions  .Process  Instance 
( ?rocess_Startup  *>  prSmainT 
SRO^size  =>  4000, 
service_perlod  *> 

basl c_pro cess .management .inf ini te_period_count ) 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  UPROC4  is  new  Process.Def inltions .Process.Instance 
(Process.Startup  «>  pr4mam7 
SRO  size  =>  4000, 
service.period  *> 

Basic_Process_Management . Infinite.Period.count ) 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 
beeln 

Use r_Process_l. MAIN; 
end  prlmaln; 


—  BODIES  FOR  USER  PROCESS  2  ~ 


procedure  pr2main  Is 
oegln 

User.Process_2.maln; 
end  pr2maln; 


—  BODIES  FOR  USER  PROCESS  3  — 


procedure  pr3main  is 
begin 

User_Process_3.maln» 
end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  is 
begin 

User_Process_4.maln; 
end  primain; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  - 

procedure  Initialize 
is 

begin 

UPROC1. Couple te_process_lnl tiaiization; 
UPROC2.Connple te_process  initialization; 
UPROC3.Complete3process_ini tializa tion; 
UPROC4.Comple te_proce 5 s^lni tiaiization ; 
end  Initialize; 

end  User  Processes; 
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»  Instruction  test  program 

link  ACS  iminmax.eod 

ACS :textlo .mio 

intio.mso 

schar.mso 

scnar.mbo 

prlmain.mso 

pr2main.mso 

pr3main.mso 

pr4main.mso 

prlmain.mbo 

pr2main.mbo 

pr3maln.mbo 

pr4main.mbo 

inf  pserpl  .mbo 

psors .mbo 

free(30  in  directory) 
output  infcnarl.eod 
objectmap 


INFLINK2.LKD 

»  instruction  test  program 

link  ACS iminmax.eod 

ACS  itextio.mlo 

intio.mso 

scnar.mso 

scnar.mbo 

prlmain.mso 

pr2maln.mso 

prSmaln.mso 

pr4main.mso 

prlmain.mbo 

pr2maln.mbo 

pr3maln .mbo 

pr4maln.mbo 

inf pserp2.mbo 

psors .mbo 

free(30  in  directory) 
output  infcftar2.eod 
objectmap 
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INFLINK3 .LKD 


»  instruction  test  program 

link  ACS  :minmax.eod 

ACS :  textio  .mlo 

intio.mso 

scnar.mso 

scnar.mbo 

prlmain.mso 

pr2main.mso 

pr3main.mso 

pr4main.mso 

prlmaln.mbo 

pr2main.mbo 

pr3main .mbo 

pr4main.mbo 

inf pserp3.mbo 

psors  .mbo 

free(30  in  directory) 
output  infcnar3.eod 
objectmap 


INFIINK3.LO 

;  instruction  test  program 

linic  ACS iminmax.eod 

ACS  stextlo.mlo 

intio.mso 

scnar .mso 

scaar.mbo 

prlmain.mso 

pr2main.mso 

pr3main.mso 

pr4main.mso 

prlmaln.mbo 

pr2maln.mbo 

pr3main.mbo 

pr4main.mbo 

inf pserp4.mbo 

psors .mbo 

fres(30  in  directory) 
output  infcnar4.eod 
objectmap 
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JCHAR1.COM 

Aada432nev 
Alda  ACS :intlo  .mss 
Alda  scnar.mss 
Aida  scnar.mbs 

Aida  Iroeers. common] prlmaln. mss 
Alda  [rovers .common] pr2maln. mss 
Alda  frogers. common] pr3main. mss 
Alda  [roeers. common] pr4maln. mss 
A  purge 

Aida  prlmaln. mbs 
Alda  pr2maln.mbs 
Alda  pr3main.mbs 
Alda  pr4main.mbs 
A puree 

Alda  [rovers .commonj dfpserpl .mbs 
Aida  [rogers .common] dfpserp2.mbs 
Alda  [roeers .common] dfpserp3  .mbs 
Alda  [rogers. common] dfpserp4. mbs 
Apu rge 

Alda  [roeers. common] lnfpserpl .mbs 
Aida  [rogers .common] inf pserp2 .mbs 
Alda  [rogers. common] Inf pserp3.mbs 
Alda  [rogers. common] inf pserp4.mbs 
Alda  [roeers .common] psors .mbs 
Apurge 

Alinfc432  [rogers. common] dflinlcl 
AUne432  [roeers. common] dflinjc2 
Alinic432  [rogers . common] dfilne3 
Slln*432  [rogers. common] dflink4 
Alln*432  [roeers. common] 1  nr  1 Inei 
AllnS432  [roeers. common]  inf  iinlt2 
All nic432  [rogers.  common]  inf  iinA3 
Slin*432  [roeers. common] inf lln*4 
Apu rge 
Adelete 
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